datetime: Stop Exposing Process-Global Objects in the datetime C-API

Feature or enhancement

Proposal:

The datetime module has its own C-API which is enabled with PyDateTime_IMPORT. From the docs:

Before using any of these functions, the header file datetime.h must be included in your source
(note that this is not included by Python.h), and the macro PyDateTime_IMPORT must be invoked,
usually as part of the module initialisation function. The macro puts a pointer to a C structure into
a static variable, PyDateTimeAPI, that is used by the following macros.

My main concern is that the PyDateTimeAPI struct is a process-global value, but it exposes object pointers (which should always be per-interpreter). We have worked around this in 3.13+, but it would be better if we could make the objects per-interpreter.

FTR, here are the objects exposed directly by PyDateTimeAPI:

• (static type) PyDateTime_DateType
• (static type) PyDateTime_DateTimeType
• (static type) PyDateTime_TimeType
• (static type) PyDateTime_DeltaType
• (static type) PyDateTime_TZInfoType
• (singleton) utc_timezone (an instance of PyDateTime_TimeZoneType)

exposed indirectly:

• (static type) PyDateTime_TimeZoneType

In order to make these objects per-interpreter, it would require changes to the datetime C-API. [^1] I expect we would leave PyDateTime_IMPORT alone. Instead, we'd need to update the macros in datetime.h to get the objects from the module associated with the current interpreter. [^2]

[^1]: These would be ABI-incompatible changes, which wouldn't be a problem unless the datetime C-API is part of the limited API).
[^2]: Anyone who is accessing the PyDateTimeAPI struct directly would have to change their code. It might make sense to provide a getter function/macro for each of the objects.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Start with the datetime C-API documentation and the datetime.h macros described in the proposal, then inspect how PyDateTimeAPI exposes the listed types and utc_timezone. Done means those objects are per-interpreter while PyDateTime_IMPORT remains unchanged, with any required getter or direct-access changes documented and tested.