Fix: handle column name collisions when combining UNION logical inputs & nested Column expressions in maybe_fix_physical_column_name

[LiaCastaneda]

Which issue does this PR close?

• Closes Input field name $f3 does not match with the projection expression ... #16063 .

Rationale for this change

This PR handles column names not matching expression names for 2 cases:

• Physical planning is failing on the uppermost projection due to inaccurate schema name coercion while building the union physical node UnionExec (see issue for wider explanation)
• There is also the case when Columns are inside other type of expression, if so the fix won't apply, this PR handles that case as well since its the same error, but from a different origin.

What changes are included in this PR?

A workaround fix in union_schema by keeping the field names of the first input + a integration test with a reproducer.

Are these changes tested?

yes, for the union cercion case, a test was added in substrait_consumer tests. For columns inside other types of expressions I added a unit test.

Are there any user-facing changes?

no

[LiaCastaneda]

Sometimes Columns can be inside other type of expressions (so they are not on the "top level") , for example:

BinaryExpr {
    left: IsNotNull(
        Column(
            Column {
                relation: Some(
                    Bare {
                        table: "left",
                    },
                ),
                name: "people_column",
            },
        ),
    ),
    op: Or,
    right: IsNotNull(
        Column(
            Column {
                relation: Some(
                    Bare {
                        table: "left",
                    },
                ),
                name: "people_column:1",
            },
        ),
    ),
},

if so the current fix won't apply, this change handles those cases by using transform_down but logic remains the same

[gabotechs]

👍 nice! LGTM

[LiaCastaneda]

@berkaysynnada since you reviewed #15580 that added maybe_fix_physical_column_name, is there any chance you can review this one when you have time? It just adds handling for the edge case when we have columns inside other expressions and the coerces UnionExec schema names to take the left one, since for now it takes the name of the side that its nullable.

[berkaysynnada]

Makes sense to me, thank you @LiaCastaneda

[berkaysynnada]

thank you also @gabotechs, I merge this after the checks

[LiaCastaneda]

thanks for the reviews @gabotechs & @berkaysynnada !