feat(isthmus): configurable fallback to dynamic function mapping

[ZorinAnton]

This PR introduces a new autoFallbackToDynamicFunctionMapping feature flag that enables automatic support for all unmapped extension functions (scalar, aggregate, and window functions) in SQL↔Substrait conversions.

[vbarua]

I'm working on a PR (#649) to try and make wiring in what you're doing here easier. We're starting to run into the limits of the existing design of the function conversion system, and I'm wary of adding more complexity before cleaning it up.

My big issue is with how we're using the feature flags for this, because we're embedding a ton of conditional configuration logic into constructors all over the codebase, which makes it very difficult to reason about an already difficult part of the system. What I would like to do is separate out the configuration from the constructors. Effectively, can we construct all the function converters we need outside of the SubstraitRelNode and SubstraitRelVisitor, and then inject them in.

[nielspardon]

@ZorinAnton can you rebase one more time and resolve the conflicts? thanks

[vbarua]

High-level question

What's the value of having a separate AutomaticDynamicFunctionMappingConverterProvider instead of expanding the DynamicConverterProvider. Put another way, would it make sense to just have a non-dynamic mode (ConverterProvider) and dynamic mode (DynamicConverterProvider)?

[ZorinAnton]

While they use similar mechanics under the hood, they serve two distinct use cases:

• DynamicConverterProvider is specifically for custom UDFs injected at runtime. It explicitly filters out the standard Substrait catalog.
• AutomaticDynamicFunctionMappingConverterProvider is a fallback for standard Substrait functions (like strftime) that exist in the official YAMLs but haven't been manually added to our static FunctionMappings.java yet.

Keeping them separate allows users to opt into custom UDF support, the standard function fallback, or both independently.