Evaluate abi3 wheels: one wheel per platform and day-one support for new Python releases

## Context

CI builds one wheel per (platform × Python version): currently 4 CPython versions across 10 platform targets, growing by 10 wheels every October. Users on a Python that shipped after our last release fall back to the sdist and need a Rust toolchain.

Building against the stable ABI (`pyo3/abi3-py311`) gives one wheel per platform that works on every CPython ≥ 3.11, including ones released after us.

## Trade-offs to measure before switching

- **Performance.** Under abi3, PyO3 loses some fast paths. The one most likely to matter here is datetime: the `chrono` conversion used for `timestamp`/`duration` values goes through the C datetime API on regular builds but through Python-level attribute access under the limited API. `size(items)` on a 1000-element list and the timestamp cases in `examples/performance/compile_execute_benchmark.py` are the numbers to compare. If abi3 costs more than ~10% on timestamp-heavy workloads, keep per-version wheels.
- **Free-threading.** abi3 wheels cannot target the free-threaded build, so if we want `cp314t` wheels (see the GIL issue) we would ship abi3 for the default build plus explicit `cp314t` wheels.
- **Reproducibility.** The `--find-interpreter` flag in `maturin-action` becomes unnecessary; `pyproject.toml` gains `[tool.maturin] features = ["pyo3/extension-module", "pyo3/abi3-py311"]`.

## Suggested approach

Build an abi3 wheel locally, run the benchmark and the full test suite against it, and post the numbers here. Decide based on the datetime cases.

Start with pyproject.toml and the maturin-action configuration, then build an abi3 wheel locally. Run examples/performance/compile_execute_benchmark.py, focusing on size(items) and timestamp cases, followed by the full test suite. Done means posting the comparison numbers and deciding whether the datetime performance trade-off supports switching.

Vom Indexierungsmodell aus dem Issue-Text verfasst.