Generalize `pyodide-version`

[henryiii]

We have a pyodide-version to allow testing for pyodide, but it's specific to pydodide; iOS (see #2447) and probably Android would like it too. It might even be useful for GraalPy, maybe even PyPy. Here's a quick thought:

We could allow the options in build-platforms to be overridden (feel free to bike shed names and structure):

[tool.cibuildwheel.override-identifier.cp313-ios_arm64_iphoneos]
url =  "https://github.com/beeware/Python-Apple-support/releases/download/3.13-b8/Python-3.13-iOS-support.b8.tar.gz"

[tool.cibuildwheel.override-identifier.cp312-pyodide_wasm32]
default_pyodide_version = "0.27.6"

It could be TOML only, and allow certain parts to be overridden: url, default_pyodide_version, and node_version. We could the last two to pyodide-version and node-version. This would work on iOS, macOS, and Windows PyPy/GraalPy.

It would work by matching with identifiers, and then checking to see if matching values are in the table; if so, they get replaced.

Eventually I've considered adding a hash, that would also be overridden if we added it (and we could clear the hash if it wasn't given, for back-compat).

Short term, I'd like to add an "experimental" warning on pyodide-version so we can remove it in 3.1 or 3.2 if we do add something like the above.

[joerick]

I like the idea. I also think it would be cool if the same mechanism could extend to users adding new identifiers, like the feature request in #1718.

It would have to be listed as an 'advanced' option, since it would be basically impossible to provide any guarantees of behaviour when it's in use. But I suppose that's already the case with manylinux-*-image and pyodide-version.

[henryiii]

I almost mentioned the ability to add new identifiers. That might be really useful for WheelNext's variants. We can play with the idea at some point.

In that case, [tool.cibuildwheel.identifier.<old_or_new_identifier>] might be a better name. Maybe it could have a "based-on", or maybe we could just require all fields if it's a new identifier. And we'd want to have a Linux / Windows (CPython) version.

[joerick]

Yeah. It'd also be good to think again about the PythonConfiguration object schemas if we're exposing them. For example, on Windows we should maybe call the version field nuget_version.