Add atomic SessionContext.with_extensions API

[timsaucer]

Which issue does this PR close?

Part 3 of 3 in the split of #1672. These are enabled as a github stack so you should be able to swab between the 3 PRs in github interface (above, next to the "Open" oval).

Rationale for this change

Working on the Ballista integration showed that chaining the low-level with_* methods is easy to get wrong: FFI codecs and planners carry a weak task-context provider bound to the context they were created against, so components can end up bound to an intermediate context that is later garbage collected. Queries then fail with TaskContextProvider went out of scope over FFI boundary, or worse, silently read stale session state.

What changes are included in this PR?

• SessionContext.with_extensions(*extensions) installs one or more extension bundles atomically. Each bundle implements the new __datafusion_session_extension__(ctx) protocol: it receives the destination context, creates fresh components bound to that exact context, and returns them as a SessionExtensionComponents (new public dataclass; SessionExtensionExportable is the matching typing protocol).
• Internally one destination context is created, factories bind against it, all codecs are installed, and the planner is bound against the final codec chains in a single state write through that context's own state_ref(). No context is derived after any provider is created, so every weak provider targets the returned context.
• Validation happens before any state change: a failing factory or invalid capsule leaves the source context untouched.
• If no bundle supplies a planner, an existing FFI planner on the source context is rebound to the new codec chains; at most one bundle may supply a planner.
• The ownership contract is documented and tested: the returned context is the strong owner, and a DataFrame outliving it fails with a clean out-of-scope error rather than crashing.
• MyPlannerExtension in the example crate is a complete Rust implementation of the protocol, including extracting the host's task-context provider from the supplied context. Its codecs record the config value they resolve through the weak provider, letting tests prove the provider targets the returned context rather than the source.
• docs/source/contributor-guide/ffi.md documents with_extensions as the preferred API for extension bundles, keeps low-level chaining as advanced usage, and includes a full three-library registration recipe.

Are there any user-facing changes?

New public APIs: SessionContext.with_extensions, SessionExtensionComponents, and the SessionExtensionExportable / __datafusion_session_extension__ protocol. The context-outlives-DataFrame ownership contract is now documented. No breaking changes to existing APIs.

[ntjohnson1]

I don't have a fully coherent thought here. IIUC this is mostly to manage life times across the FFI boundary. I do wonder if there is a slightly cleaner way to mange this but this seems fine for now to provide a safer avenue.

I wonder if it makes sense to have a todo for some datafusion python extension skill/s. Being able to generate the 3 library example from the skill might be a nice smoke test to verify. I suspect after getting things setup for ballista/datafusion-distributed keeping it up to date shouldn't be too bad but I do suspect it will require some guidance to make sure they are doing it safely.

[ntjohnson1]

This is redundant with the type hint

[ntjohnson1]

It might be nice to have a little sample we import as a part of the pytest conf so these examples don't go stale. Through the stacked PRs lots of doctest skip