Bugfix - Projection Removal Conditions

[berkaysynnada]

Which issue does this PR close?

Closes #9211.

Rationale for this change

It is a minor PR fixing the bug in the mentioned issue.

What changes are included in this PR?

is_projection_removable() has some condition checks based on fields of projection and its input. Field comparison is not safe. Instead, we should check the input indices of expressions to ensure projection does not change the input table.

Are these changes tested?

A test is added covering the fix.

Are there any user-facing changes?

[alamb]

Thank you @berkaysynnada -- this change makes sense to me

I also manually ran the test cases from #9211 and they get the expected output now

❯ create table a (
    a bigint
) as values
(1),
(2),
(3),
(4),
(5),
(6);
0 rows in set. Query took 0.025 seconds.

❯ create table b (
    a bigint
) as values
(3),
(4),
(7),
(9);
0 rows in set. Query took 0.008 seconds.

❯ copy (select * from a) to 'a.parquet';
+-------+
| count |
+-------+
| 6     |
+-------+
1 row in set. Query took 0.023 seconds.

❯  copy (select * from b) to 'b.parquet';
+-------+
| count |
+-------+
| 4     |
+-------+
1 row in set. Query took 0.011 seconds.

❯ select * from 'a.parquet' a left join 'b.parquet' b on a.a = b.a;
+---+---+
| a | a |
+---+---+
| 5 |   |
| 1 |   |
| 6 |   |
| 4 | 4 |
| 3 | 3 |
| 2 |   |
+---+---+
6 rows in set. Query took 0.020 seconds.

❯ select a.a, b.a from (select 1 as a) a cross join (select 2 as a) b;
+---+---+
| a | a |
+---+---+
| 1 | 2 |
+---+---+
1 row in set. Query took 0.009 seconds.

❯ select b.a, a.a from (select 1 as a) a cross join (select 2 as a) b;
+---+---+
| a | a |
+---+---+
| 2 | 1 |
+---+---+
1 row in set. Query took 0.008 seconds.

cc @helgikrs

[comphead]

lgtm thanks @berkaysynnada