Clean-up pyatomic headers

[colesbury]

Feature or enhancement

Now that #108337 is done, we have three atomic headers. We should be able to remove pycore_atomic.h and pycore_atomic_funcs.h and replace their usages with calls to pyatomic.h.

cc @vstinner

Linked PRs

• gh-109693: Remove pycore_atomic_funcs.h #109694
• gh-109693: Use pyatomic.h for signal module #110477
• gh-109693: Use pyatomic.h for signal module #110480
• gh-109693: Update pycore_interp.h to use pyatomic.h #110604
• gh-109693: Update _gil_runtime_state.last_holder to use pyatomic.h #110605
• gh-109693: Update _gil_runtime_state.locked to use pyatomic.h #110836
• gh-109693: Update pyruntimestate._finalizing to use pyatomic.h #110837
• gh-109693: Remove pycore_atomic.h #110992

[colesbury]

@vstinner, For pycore_atomic.h, I'm not sure whether to keep _Py_atomic_address and _Py_atomic_int or not.

[vstinner]

I was fine to remove pycore_atomic_funcs.h at once since it's only used by _PyUnicode_FromId() which is... no longer used by Python itself!

To remove pycore_atomic.h, I would prefer to make baby steps: convert usage one by one. For example, you can start by converting signal handlers: get_handler() and set_handler() in Modules/signalmodule.c, and also the two "tripped" variables.

If someone goes wrong, it would be easier to revert changes if they have limited scope. Also, smaller PRs are easier to review :-)

[corona10]

@colesbury @vstinner
I am working on the following fields.

cpython/Include/internal/pycore_gil.h

Lines 28 to 31 in 67e8d41

	_Py_atomic_address last_holder;
	/* Whether the GIL is already taken (-1 if uninitialized). This is
	atomic because it can be read without any lock taken in ceval.c. */
	_Py_atomic_int locked;