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.