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

pyproject.toml と maturin-action の設定から始め、その後ローカルで abi3 wheel をビルドします。examples/performance/compile_execute_benchmark.py を実行し、size(items) と timestamp のケースに重点を置いたうえで、完全なテストスイートを実行します。比較結果の数値を投稿し、datetime のパフォーマンス上のトレードオフが切り替えを支持するかどうかを判断すれば完了です。

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.