[3.13] gh-87135: Hang non-main threads that attempt to acquire the GIL during finalization (GH-105805)

[gpshead]

Instead of surprise crashes and memory corruption, we now hang threads that attempt to re-enter the Python interpreter after Python runtime finalization has started. These are typically daemon threads (our long standing mis-feature) but could also be threads spawned by extension modules that then try to call into Python. This backport documents that the PyThread_exit_thread public C API should not be used (deprecated in 3.14) as there is no plausible safe way to accomplish that on any supported platform in the face of things like C++ code with finalizers anywhere on a thread's stack. Doing this was the least bad option.

(cherry picked from commit 8cc5aa4)

• Issue: pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful #87135

---

📚 Documentation preview 📚: https://cpython-previews--137827.org.readthedocs.build/

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @gpshead for commit f412737 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F137827%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[serhiy-storchaka]

I cannot say it LGTM, but it looks less bad than anything else. ☹️ It seems there are no good solutions here.

[gpshead]

I'll leave this PR around for reference, but do not intend to merge it so late in the 3.13 release cycle even though I believe this least bad option is the only viable one. It is a behavior change, even if the existing behavior is an undertiministic sometimes crashing or sometimes working. See #87135 (comment) and #123940 (comment) for rationale from @encukou about invasiveness of such a change as in a bugfix release.