Extract shared ParquetReadPlan for leaf column resolution

[friendlymatthew]

Note: please review from the second commit. This PR is currently based off of #20854

Rationale for this change

This PR extracts a reusable build_parquet_read_plan function and ParquetReadPlan struct from the row filter's FilterCandidateBuilder::build

Today, struct-aware leaf projection only exists in the row filter path. The opener still uses ProjectionMask::roots which reads all leaves of a struct even when only one field is needed. By pulling this logic into a shared abstraction, the opener can reduce unnecessary I/O for struct-heavy schemas

[adriangb]

I take it the idea is that this can be re-used for the projection side of things because it was written in a reusable manner, even thought at the moment it is only used for the row filter?

I generally like this change :)

[adriangb]

Under what circumstances would get_field accept non-string literal arguments? Would this be a column e.g. get_field(struct_col, fields_col)?

[friendlymatthew]

In practice, get_field will always receive string literals. This is enforced at different levels:

• At runtime, the udf requires all field_name args to be scalars
• At planning time, field names must be non-empty strings

The None fallback is purely defensive. It's not likely that we'll hit this in practice, but in the case we do, we'll just read out the entire struct. Though, we can also err here like we did before

[adriangb]

I think we need to either:

• Do something slower but correct (read out entire struct)
• Error explicitly

Since we are doing one of these I think it's good for now 👍🏻

[friendlymatthew]

I take it the idea is that this can be re-used for the projection side of things because it was written in a reusable manner, even thought at the moment it is only used for the row filter?

Yes exactly. Here's a PR that does exactly just that! #20925