Allow installation of the free-threaded python-build-standalone builds

[ncoghlan]

The suggested PyPA convention to indicate the free-threaded variant of CPython is to append a t or _t suffix. That is, the following should both request the free-threaded build of CPython from pbs-installer:

python_implementation = "cpython@3.13.0t"

python_implementation = "cpython@3.13.0_t"

To allow stack publishers to express this in a less cryptic way, this field should accept an inline table in addition to the string format:

python_implementation = {"name": "cpython", "version": "3.12.7", "free-threaded": false}

python_implementation = {"name": "cpython", "version": "3.13.0", "free-threaded": true}

free-threaded may be omitted, and defaults to the default behaviour for that version of Python (which is currently always the GIL-enabled "free-threaded": false builds).

(Note: #84 changes the name of the fully_versioned_name field to instead be python_implementation, so that is the name used in the examples above).

[ncoghlan]

One question that will need to be resolved here is what to do with the python_implementation field in the runtime layer output metadata.

My initial inclination is to say that the output metadata will always use the shorthand string form, with the trailing free-threaded build marker normalised to just t when the last segment in the version number (excluding the free-threading marker) is fully numeric, and _t when the last segment is alphanumeric. That way, the metadata for existing non-free-threaded runtime layers won't change.

The obvious alternative would be to always store the exploded mapping form, but that feels like it would be adding complexity to the output metadata format without adding substantial expressivity (if we were to add more metadata about the interpreter implementation, an ecosystem level standardised format like the one proposed in PEP 739 seems like it would be a better direction)