Implement CastExtension for extensible casting to/from extension types - #27383

Which issue does this PR close?

• Closes Support pluggable cast resolution to support casting to and from extension types #20755

Rationale for this change

Long ago in #21071 I prototyped cast handling so we can finally get the fabled UUID -> string cast to work. In general, there is no built-in way to teach DataFusion how to handle casts that are not handled by arrow-rs' cast(). Notably for extension types because they cannot be captured by the DataType, which is the only thing cast() knows about.

What changes are included in this PR?

This PR intoduces a CastExtension, whose job is to override casts to/from an arbitrary type pair or fall back to the existing implementation. Much of the casting in DataFusion has already been consolidated into nested_struct.rs to handle the casting of struct types, which already has plumbing for recursive types (e.g., lists of structs today, but lists of extensions if we implement it there), so that's where this implementation sits.

This PR just implements the trait and pipes it through casting in nested_struct.rs. To actually plumb through the cast we need a way to pipe this through to the planner...I can do that here if anybody would like. I also didn't implement a variant of the CastExtension that aggregates other cast extensions...in practice you'd have a registry that dispatches to individually registered cast extensions.

I didn't implement this as part of the DFExtensionType trait because casting is an interaction between two types, one or both of which may be an extension type.

There are some alternatives: casts that occur purely in SQL can be overridden after 55.1 using an optimizer rule or custom planner that replace Expr::Cast or Expr::TryCast with function calls or custom physical expressions; however, these are only a subset of casts that occur in DataFusion. Casts inserted as part of the process of combining multiple Parquet files can be worked around with the physical expression adapter, but may other types of casts have no workaround.

What is the testing strategy for this PR?

Inline tests directly in the file, including all nested branches

Are there any user-facing changes?

Existing APIs should be unchanged, this adds a new API.