fix(isthmus): convert extended expressions with the provider's converter

[alexandrefimov]

SqlExpressionToSubstrait built its own RexExpressionConverter from the scalar function converter alone. That varargs constructor takes the whole call-converter list, so the list on this path was just that one converter and CallConverters.defaults(...) never reached it — CAST, CASE, the execution-context variables and the array and map constructors were unconvertible as extended expressions while converting fine inside a plan.

Taking the converter from ConverterProvider.getRexExpressionConverter rather than assembling a second one here also means a provider that overrides that method is honoured on this path, as it already is when converting a plan, and that the window function converter and type converter are the provider's rather than null and TypeConverter.DEFAULT. Only the call-converter half and the provider hook are pinned by tests; a marker TypeConverter cannot isolate the third, because SqlConverterBase already uses the provider's type converter for the schema, so such a test passes against the old constructor too.

getRexExpressionConverter is passed null for the relation visitor: an expression that stands alone has no relation to visit. Nothing in this path produces a subquery to convert -- validating an extended expression that holds one throws inside Calcite first, a scalar subquery and IN/EXISTS alike -- so the converter names what is missing instead of dereferencing it. visitFieldAccess did the same dereference for an outer reference, and visitOver for the window function converter that three of the four constructors leave null; both say so now.

Naming what is missing has to stay out of the way of the message that names the call. callConversionFailureMessage converted each operand again to render its type, so an unconvertible call with a subquery operand reported the operand's failure rather than the call's; the types come off the nodes now.

The expressions the scalar function converter does not claim are pinned by what they convert into -- CAST, IF_THEN, EXECUTION_CONTEXT_VARIABLE, two LITERALs and, since the same wiring admits it, the WINDOW_FUNCTION of ROW_NUMBER() OVER (...). The round trip they used to share compares a proto against the one converting it back produces, which holds whatever the conversion made of them, and they no longer feed the duplicate-column test, where they threw before the expression was parsed.

Closes #1165.

[nielspardon]

Does an execution-context variable belong in an ExtendedExpression at all? algebra.proto ties it to ExecutionBehavior, which only Plan carries, so CURRENT_DATE now converts into a message with nowhere to record whether it is evaluated once or per record — and the same widening makes ROW_NUMBER() OVER (...) convert, untested.

The description needs a rewrite before merge: its subquery paragraph describes the javadoc that commit 2 replaced, and i + (SELECT 1) is not rejected by the validator — it converts, to a field reference.

The half-honoured provider getters behind getCallConverters() are #1048; this also unblocks dropping #1166's javadoc caveat that nothing configured on the provider reaches this path.

[alexandrefimov]

On the execution-context variable: the gap you point at is there. ExtendedExpression declares version, extension_urns, extensions, referred_expr, base_schema, advanced_extensions and expected_type_urls -- execution_behavior is on Plan alone -- so a CURRENT_DATE in an extended expression carries no statement of whether it is evaluated once or per record.

I would rather not refuse it here, though. The message the spec defines admits an Expression, and this conversion has no rule the plan path does not; refusing would make the extended-expression path narrower than the message it produces, on a question the spec has not answered. What the wiring can do is stop being silent about it, which is what the split test now does: CURRENT_DATE is pinned as EXECUTION_CONTEXT_VARIABLE and ROW_NUMBER() OVER (...) as WINDOW_FUNCTION, so neither arrives untested and both are visible to whoever settles the semantics.

Happy to raise the behaviour question upstream, or to refuse both here if you would rather this path stay to what an extended expression can fully describe -- your call, and I have no strong second preference.

[nielspardon]

Thanks — the rest all look good.