Implement stack overflow protection for linux based on actual stack depth

[markshannon]

Linux doesn't offer an API for determining the current stack bounds, at least not that I am aware of.

This means we will need to probe the stack using a SIGSEGV handler and longjmp/setjump.
It is somewhat ugly but should work.

Actually, it looks like pthread_get_stackaddr_np might work, and avoid all the complexity of the signal handler. In theory, it should work for MacOS as well.

Linked PRs

• GH-130396: Use computed stack limits on linux #130398
• GH-130396: Broaden definition of "optimized" for gdb tests #130550
• GH-130396: Increase trashcan overhead #130552
• GH-130396: Include stack margin for debug windows builds #130554
• [3.13] GH-130396: Treat clang -Og as optimized for gdb tests (GH-130550) #130572
• [3.12] GH-130396: Treat clang -Og as optimized for gdb tests (GH-130550) #130573
• [3.11] GH-130396: Treat clang -Og as optimized for gdb tests (GH-130550) (GH-130573) #130593
• gh-130396: Fix thread sanitizer crashes on stack overflow tests #130966
• GH-130396: Work around for broken pthread_get_stackaddr_np on Emscripten #131088

[encukou]

This broke two buildbots (both can be seen in the pre-merge run):

• AMD64 Windows Server 2022 NoGIL (tier 1): test_trashcan_python_class1 loops with endless repetition of Exception ignored in audit hook: RecursionError: Stack overflow (used 11729 kB)
• AMD64 Fedora Stable Clang 3.x (tier 2): several test_gdb failures.

Do you have any leads on these issues?