More global allocator reentrancy issues in `park` and `unpark`

GlobalAlloc guarantees that implementors can use thread::current, thread::park and thread::Thread::unpark in global allocators without being called reentrantly.

However, thread uses synchronization internally and we have some platforms where the std::sys implementations of that can fail. This causes them to call panic!, which is inappropriate for the thread APIs because panicking invokes the global allocator. See #160793 for how this is violated in thread::current.

The platform implementations of Parker live in library/std/src/sys/sync/thread_parking/ and are chosen using cfg_select.

The following implementations of Parker::park/Parker::unpark can call the global allocator by panicking:

I did not find panics in the remaining implementations, namely darwin, futex, windows7 and unsupported; with the caveat that futex is split into more platform-specific futex implementations. I'll get around to reviewing those (this issue took much longer to write than I expected).

As an aside, note that thread::park itself handles unwinds from Thread::park using an abort-on-drop guard. However, it should never even panic, since that already violates our guarantees to the global allocator.

@rustbot label T-libs A-thread I-unsound

Start by reading the Parker implementations in library/std/src/sys/sync/thread_parking/xous.rs, pthread.rs, and id.rs, then inspect the SGX implementation under library/std/src/sys/pal/ and the park wrapper in library/std/src/thread/functions.rs. Trace which panic or unwrap paths can invoke the global allocator. Done means the identified park and unpark paths no longer violate the GlobalAlloc reentrancy guarantee, with the affected platform implementations checked.