`thread::current` may indirectly call `Arc::new_uninit_in(System)` which may call an untrusted alloc error hook

Related to #160793, but a platform-independent reentrancy issue with alloc_error_hook that potentially impacts more code.

The implementation of thread::current may require allocating a new Thread object.

Because GlobalAlloc guarantees that std::thread::current will not invoke the global allocator reentrantly, Thread uses an Arc<_, System> internally. However, the call to Arc::new_uninit_in(System) may involve a call to handle_alloc_error. Using feature(alloc_error_hook), we can thus call the global allocator reentrantly from thread::current. In particular, a hook just calling panic! (or even just resume_unwind) does so.

I can't give a demo, because it would require getting System to fail at the right moment.

Relevant code from std:
https://github.com/rust-lang/rust/blob/4667d75565e47ba5df36c0df598c556b543e8624/library/std/src/thread/current.rs#L289-L301
https://github.com/rust-lang/rust/blob/4667d75565e47ba5df36c0df598c556b543e8624/library/std/src/thread/thread.rs#L92-L102

@rustbot label T-libs A-thread requires-nightly A-allocators I-unsound A-global-allocator-reentry

Read library/std/src/thread/current.rs around lines 289-301 and library/std/src/thread/thread.rs around lines 92-102, then trace Arc::new_uninit_in(System) through allocation failure handling. Confirm whether thread::current can invoke an alloc_error_hook reentrantly and identify a design that preserves the GlobalAlloc guarantee; done means the reentrancy issue is resolved and covered by an appropriate regression test.