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

# 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:

```python
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`.

Start with SessionExtensionComponents, SessionExtensionExportable, and the with_extensions transaction in crates/core/src/context.rs; compare them with the MyPlannerExtension example in examples/datafusion-ffi-query-planner-example. Begin with the suggested udfs and catalog_providers scope, then resolve collision handling and registration ordering. Done means bundles can install those components atomically through with_extensions without breaking existing bundles.

索引モデルが issue の本文から書いたものです。