Refactor to store CPython ABI metadata in a struct combining two enums

[ngoldbaum]

Towards #3064.

This is purely refactoring, there should be no functional changes as a result of this.

Currently the build metadata special-cases ABI3 builds or more generally assumes stable ABI builds and ABI3 builds are the same thing. With PEP 803 and the new abi3t ABI in Python 3.15, that is no longer the case.

This replaces the old ABI3Version enum with a new struct combining two enums:

/// struct describing ABI layout to use for build
#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub struct StableAbi {
    /// The "kind" of stable ABI. Either abi3 or abi3t currently.
    pub kind: StableAbiKind,
    /// The minimum Python version to build for.
    pub version: StableAbiVersion,
}

/// Python version to use as the abi3/abi3t target.
#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub enum StableAbiVersion {
    /// Stable ABI wheels will have a minimum Python version matching the
    /// version of the current Python interpreter
    CurrentPython,
    /// Stable ABI wheels will have a fixed user-specified minimum Python
    /// version
    Version(u8, u8),
}

/// The "kind" of stable ABI. Either abi3 or abi3t currently.
#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub enum StableAbiKind {
    /// The original stable ABI, supporting Python 3.2 and up
    Abi3,
}

StableAbiVersion is just the old Abi3Version enum renamed since the concept of a minimum supported version is shared by abi3t.

I have a branch that adds an Abi3t variant for StableAbiKind. My goal with this PR is to make reviewing the subsequent PR adding abi3t support easier.

Also see PyO3/pyo3#5924 where I made a similar change in PyO3. Here in Maturin I needed different types but in principle I could make the two implementations use shared code. I'm not sure if that's actually useful for anything in practice.

[Copilot]

Pull request overview

Refactors how PyO3/CPython stable-ABI build metadata is represented by replacing the old Abi3Version enum with a StableAbi struct combining StableAbiKind + StableAbiVersion, to prepare for future abi3t support (PEP 803) while aiming to keep current behavior the same.

Changes:

• Introduces StableAbi, StableAbiKind, and StableAbiVersion, and threads them through bridge detection and public exports.
• Updates build orchestration, wheel tag generation, and binding generation to use stable_abi metadata.
• Updates tests and project scaffolding to the new stable_abi field name.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/python_interpreter/resolver.rs	Switches resolver logic from abi3 version enum to stable_abi.version.
src/python_interpreter/mod.rs	Adjusts stable-API capability detection for interpreters.
src/python_interpreter/discovery.rs	Updates test bridge models to use stable_abi field name.
src/new_project.rs	Updates generated project bridge config to initialize stable_abi: None.
src/lib.rs	Re-exports new stable-ABI types from bridge.
src/ci/github/tests.rs	Updates CI generation tests to pass StableAbi instead of Abi3Version.
src/build_orchestrator.rs	Refactors stable-ABI wheel building/tagging paths around StableAbiKind + StableAbiVersion.
src/build_options.rs	Updates build options tests to use StableAbi::from_abi3_version.
src/bridge/mod.rs	Defines new stable-ABI types and replaces PyO3.abi3 with PyO3.stable_abi.
src/bridge/detection.rs	Generalizes feature parsing to stable-ABI kind/version, preparing for additional kinds.
src/binding_generator/pyo3_binding.rs	Refactors binding generation to accept an optional StableAbiKind and centralizes ext suffix logic.