Read transforms via expressions. Part 1: Just compute the expression and return it.

[nicklan]

What changes are proposed in this pull request?

This is the initial part of moving to using expressions to express transformations when reading data. What this PR does is:

• Compute a "static" transform, which is just a set of column expressions that need to be passed directly through without change, or enough metadata for lower levels to fill in a "fixup" expression
• The static transform is passed into the iterator that parses each Add file
• When parsing the Add file, if there are needed fix-ups (just partition columns today), the correct expression is created, and inserted into a row indexed map
• This map is returned so the caller can find out for a given row what, if any, expression needs to be applied when reading the specified row

Follow-up PRs will:

1. Propagate this information though when using visit_scan_files
2. Actually use the data to do transformation
3. Remove transform_to_logical entirely and clean up associated code

Each of those are more invasive and end up touching significant code, so I'm staging this as much as possible to make reviews easier.

How was this change tested?

Unit tests, and inspection of resultant expressions when run on tables

[nicklan]

Note this is a significant change as we not longer expose this function. In discussion so far we've agreed that it basically should never have been pub, and I just made a mistake when doing so. An engine should call scan_data which mostly just proxies to this, but doesn't expose internal details to the engine.

Open to discussion though.

[zachschuermann]

pub(crate) SGTM!