refactor(isthmus): unify ConverterProvider customization on the builder

[nielspardon]

Context

Review discussion on #1036: now that ConverterProvider has a builder, there are two
customization mechanisms — the builder and subclassing — and they can be mixed. As
@vbarua noted,
it isn't obvious which one a user should reach for, and the built-in subclasses are
themselves an example of the ambiguity:

// today
new DynamicConverterProvider(ConverterProvider.builder().extensions(extensions))

// could plausibly be
ConverterProvider.builder()
    .extensions(extensions)
    .scalarFunctionConverter(...)
    .sqlOperatorTable(...)
    .build()

What's missing

DynamicConverterProvider and AutomaticDynamicFunctionMappingConverterProvider subclass
rather than configure because the builder can't express what they override:

• getSqlOperatorTable() — both chain dynamically generated operators onto the base table.
• getCallConverters() — DynamicConverterProvider appends an extra ScalarFunctionConverter.
  Addressed by feat(isthmus): let the builder transform the call converter list #1166; see the proposal below. That append turns out to be a duplicate that never
  fires (refactor(isthmus): DynamicConverterProvider appends a duplicate ScalarFunctionConverter that never fires #1208), so this half may be a deletion rather than a migration.

getSqlOperatorTable() needs the derived extensions/type factory to compute its value, so
exposing it as a plain builder setting also means giving callers a way to build those pieces
(e.g. a public helper that turns an extension collection into the dynamic operators).

Proposal

1. Add callConverters to ConverterProvider.Builder. Done in feat(isthmus): let the builder transform the call converter list #1166, as
   callConverters(UnaryOperator<List<CallConverter>>) — a transform over the assembled list
   rather than a replacement for it. A plain list cannot work here: scalarFunctionConverter goes
   last in getCallConverters(), is derived during construction, and DynamicConverterProvider
   reassigns it after super(builder) returns, so anything frozen at build() captures the
   pre-override converter; a caller supplying the whole list themselves would also trip the feat(isthmus): introduce a ConverterProvider builder #1036
   guards. The transform is handed the built-ins with late-bound values in place and runs per
   conversion, so it expresses insert-at-position, append, prepend, replace and filter.
2. Add sqlOperatorTable to ConverterProvider.Builder. Whether this wants the same transform
   shape is open — unlike the converter list it has no derived-late component, so a plain setting
   may be enough.
3. Expose the derivation helpers the dynamic providers use so a caller can assemble the same
   configuration. Smaller than originally scoped: no helper is needed for the call-converter half,
   since the transform already receives the derived converter.
4. Re-express both dynamic providers as builder configuration (static factory methods returning
   a preconfigured Builder), and deprecate the subclasses.
5. Document one recommended path: the builder for composition, subclassing only for behaviour
   that must be computed per call.

Notes

#1036 added guards that throw IllegalArgumentException when a builder passed to either dynamic
provider configures a function converter those providers derive themselves — a stopgap that makes
the discarded-setting case loud. This issue is about removing the need for that overlap.

[nielspardon]

Refinement to item 1 from reviewing #1166: callConverters should be a transform over the assembled list, UnaryOperator<List<CallConverter>>, not a List.

A plain list setter can't express the configuration the dynamic providers need. scalarFunctionConverter goes last in getCallConverters(), is derived during construction, and DynamicConverterProvider reassigns it after super(builder) returns — so a list frozen at build() captures the pre-override converter and silently drops dynamic function resolution. A caller assembling the full list themselves would also have to construct a ScalarFunctionConverter, which is exactly what the #1036 guards reject.

Applying a transform inside getCallConverters() avoids both: the operator receives the built-ins with the late-bound typeConverter and scalarFunctionConverter already in place, and it runs per conversion rather than once at build time. It covers insert-at-position, append, prepend, replace and filter, so ordering is explicit at the call site instead of something the caller has to reconstruct.

That shrinks item 2 as well — no derivation helper is needed for the call-converter half, since the transform is handed the derived converter. sqlOperatorTable still needs one for the dynamic operators.