feat(datafusion): allow configuring ExpressionConvertor on VortexFormat and VortexFormatFactory

[haohuaijin]

Rationale for this change

VortexSource::with_expression_convertor already allows swapping in a custom ExpressionConvertor, but there was no way to configure one when the source is created through VortexFormat / VortexFormatFactory — the path used by ListingTable and CREATE EXTERNAL TABLE. Engine integrations that need a custom expression conversion or pushdown strategy could not use it through those entry points.

This PR plumbs an optional ExpressionConvertor through VortexFormatFactory and VortexFormat so that every VortexSource they create picks it up. This makes the workaround suggested in #8763 (rejecting unsupported pushdowns via a custom convertor) usable from the ListingTable path, where the source is created by the format rather than constructed directly.

• Related to: Expression handling in VortexSource isn't consistent, and might cause runtime errors or other issues. #8763

What changes are included in this PR?

• VortexFormatFactory::with_expression_convertor and VortexFormat::with_expression_convertor builder methods; the convertor is forwarded through FileFormatFactory::create / default() and FileFormat::file_source into the VortexSource.
• Re-export ProcessedProjection from vortex_datafusion::convert. The ExpressionConvertor trait was already public, but split_projection returned a type that downstream crates could not name. The trait documentation now includes a compiling downstream implementation example.
• Manual Debug impls for VortexFormat / VortexFormatFactory that report whether a custom convertor is set (the trait object itself is not Debug).

How was this tested?

• Unit tests cover VortexFormat directly and both VortexFormatFactory entry points (create and default). A rejecting test convertor verifies that can_be_pushed_down is consulted, the filter is reported as PushedDown::No, and convert is not called for rejected filters.
• An end-to-end CREATE EXTERNAL TABLE test registers a factory with a custom convertor, inserts data, executes a filtered query, verifies both can_be_pushed_down and convert are called, and validates the result.
• A compiling doctest implements ExpressionConvertor through the public vortex_datafusion::convert API, proving downstream crates can name ProcessedProjection.

Validation:

• cargo nextest run -p vortex-datafusion
• cargo test --doc -p vortex-datafusion
• cargo clippy -p vortex-datafusion --all-targets --all-features -- -D warnings
• cargo +nightly fmt --all -- --check

What APIs are changed? Are there any user-facing changes?

• New public methods: VortexFormatFactory::with_expression_convertor, VortexFormat::with_expression_convertor.
• Newly re-exported: vortex_datafusion::convert::ProcessedProjection.
• No behavior change for existing users: without a configured convertor, sources keep using DefaultExpressionConvertor as before.

---

This PR was developed with AI assistance; all changes were reviewed by the haohuaijin.

[codspeed-hq]

Merging this PR will degrade performance by 31.44%

❌ 1 regressed benchmark
✅ 1841 untouched benchmarks
⏩ 44 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	decompress[u64, (1000, 16)]	70.4 µs	102.7 µs	-31.44%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing haohuaijin:feat/format-expression-convertor (3e6edca) with develop (f9d2abb)}

Footnotes

1. 44 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[AdamGS]

Thank you for your contribution! definitely a missing piece.