Noting a design consideration that I only picked up in the latest PR review: when exposed as part of a non-opaque struct, the type used for TSS keys becomes part of Python's ABI, which means the API design in the PEP is going to have to handle making the struct fully opaque when Py_LIMITED_API is defined.

My proposal for handling that:

- update all of the API functions to accept Py_tss_t by pointer rather than by value
- update the Py_tss_t definition to be an opaque struct when Py_LIMITED_API is defined
- add PyThread_tss_alloc and PyThread_tss_free functions for dynamic allocation of key storage (since static allocation won't be possible in the Py_LIMITED_API case)

My main rationale for going to that level of effort is that the current thread local storage API is available when Py_LIMITED_API is defined, so its replacement should be available as well. However, exposing NATIVE_TSS_KEY_T as part of the stable ABI would prevent us from switching from `int` to a platform specific implementation for platforms that start out using the generic emulation.

If issue #29881 ever became a public API, it would then be useful for managing the lifecycle of dynamically allocated TSS keys in extension modules that restrict themselves to the stable ABI.