Extend SessionContext.with_extensions to cover additional extension points (functions, catalogs, object stores)

Beginne mit SessionExtensionComponents, SessionExtensionExportable und der with_extensions-Transaktion in crates/core/src/context.rs; vergleiche sie mit dem MyPlannerExtension-Beispiel in examples/datafusion-ffi-query-planner-example. Beginne mit dem vorgeschlagenen Umfang für udfs und catalog_providers, und kläre anschließend die Kollisionsbehandlung und die Registrierungsreihenfolge. Die Aufgabe ist abgeschlossen, wenn Bundles diese Komponenten atomar über with_extensions installieren können, ohne bestehende Bundles zu beeinträchtigen.

Is your feature request related to a problem or challenge?

#1672 adds SessionContext.with_extensions(*extensions), which installs extension bundles atomically: each bundle implements __datafusion_session_extension__(ctx) and returns a SessionExtensionComponents containing logical extension codecs, physical extension codecs, and optionally a query planner. Those components carry weak task-context providers, so the atomic protocol exists to guarantee they bind to the exact context returned to the user.

Extension libraries typically provide more than codecs and a planner. A distributed engine or data-source library may also ship scalar/aggregate/window/table functions, catalog providers, table providers, object stores, and physical optimizer rules. Today the user must install those with separate register_* calls after with_extensions, which defeats the goal of a one-line installation of everything a library provides.

Describe the solution you'd like

Extend SessionExtensionComponents with additional optional fields so a single bundle can declare every extension point its library offers:

• udfs, udafs, udwfs, udtfs (or a single functions tuple with type dispatch) — accepting both FFI-capsule and Python-native definitions, flowing through the existing register_* paths
• table_providers: tuple[tuple[str, provider], ...] — named table registrations
• catalog_providers: tuple[tuple[str, provider], ...]
• object_stores: tuple[tuple[str, store], ...] — keyed by scheme
• physical_optimizer_rules

SessionExtensionComponents is a frozen dataclass with defaulted fields and the Rust _install_extensions helper is private, so this is backward compatible and can be added incrementally. A distributed engine bundle could then install codecs, planner, its UDFs, and a scheduler-backed catalog in one call:

ctx = SessionContext(config).with_extensions(MyEngineExtension(address))

Declarative components are preferred over having factories call ctx.register_udf(...) on the context view directly: the host can validate every component before mutating anything, the configuration-only contract for factories stays honest, and installation order becomes explicit (codecs, then planner, then registrations, with fallible steps first).

Design decisions to settle during implementation:

1. Catalog list sharing. The derived context shares its catalog provider list with the source context, so catalog registrations are visible in the source and are not rolled back if a later step fails. Registering catalogs last, after all fallible steps, closes most of the hole. Cloning the catalog provider list at derivation would give true isolation but diverges from the semantics of every other with_* method.
2. Name collisions. Two bundles registering the same UDF name or catalog name should probably be an error (matching the one-planner rule) rather than last-wins, since registrations have no fall-through semantics like codec chains do.

Suggested starting scope: udfs and catalog_providers, with collision handling as an error.

Describe alternatives you've considered

Factories can already register functions and catalogs imperatively on the context view passed to __datafusion_session_extension__, since the view shares the destination context. This works but hides side effects inside the factory, cannot be validated up front, and leaves partial registrations behind on failure.

Keeping registrations as separate user-facing register_* calls after with_extensions remains possible, but each library then documents its own multi-step setup recipe, which is the situation with_extensions was introduced to remove.

Additional context

Follow-up to #1672. Relevant pieces there: SessionExtensionComponents, SessionExtensionExportable, the with_extensions transaction in crates/core/src/context.rs, and the MyPlannerExtension example bundle in examples/datafusion-ffi-query-planner-example.