feat: add generic runtime binding for physical expressions

[gene-bordegaray]

Which issue does this PR close?

• Related to support dynamic filtering on partitioned data from file source #20195

Rationale for this change

DataFusion has a generic way to snapshot dynamic PhysicalExprs at runtime via snapshot()/snapshot_physical_expr(...), but it does not have a corresponding way to bind runtime context into a dynamic expression.

This PR adds the missing API for this. The need for this is partition-index dynamic filtering. When a scan is opened or execution partition i, we want to bind partition-aware dynamic filters to that partition.

However, this API is not specific to dynamic filtering. It is a reusable physical-expression capability anywhere an expression needs runtime specific context.

Trino's design

I investigated Trino's design.

There runtime filtering is done live objects exposed in the connector (TupleDomain, DynamicFilter). Essentially, it:

1. Inserts dynamic filter markers into the plan
2. Creates DynamicFilter objects that collects values for the filter. It uses a blocking and completion signals to determine when the filter is done accumulating and can pushdown.
3. It merges the dynamic filter into a global expression and uses this predicate.

This differs from the DataFusion's approach since:

• Ours is expression based, so extending that is cleaner fit than introducing a new contract.
• Trino is connector-first. Its design is centered around a live connector object, DynamicFilter, that supports waiting, refinement, and split-enumeration-time pruning. This is different in our approach as the API we expose is engine-centric in PhysicalExpr.
• Trino collects tables per partition, but then unions them into a global filter. This is not what we want to do in our work, rather we want to map each partition's tighter filter to the corresponding partition on the probde side.

Basically Trino says "here is a specific object we have for dynamic filtering" and our approach is "we have this general filter represented as an expression, and some of this is dynamic (at runtime)". I think our solution is more involved and less explicit but very nice as it treats the predicate as a single entity, this extension further enhances that.

With this I found that the best approach to this problem is a missing generic API to bind runtime information to a PhysicalExpr. This solves the partition-aware dynamic filtering issue, but is not limited to this.

What changes are included in this PR?

Added a good description above.

Are these changes tested?

Yes added unit tests:

• cargo test -p datafusion-physical-expr-common

Are there any user-facing changes?

Yes, there is a new public physical expression API:

• PhysicalExpr::bind_runtime(...)
• bind_runtime_physical_expr(...)
• bind_runtime_physical_expr_opt(...)

No breaking chnages, only additive.

[gene-bordegaray]

cc: @adriangb @gabotechs @LiaCastaneda