Inadequate unwind protection for log calls under DX12

[Xaeroxe]

Description
The log macros and functions are internally calls out to "whatever zany stuff the Rust ecosystem has dreamt up" so it's nearly impossible to prove they won't panic. Currently wgpu is using log while behind FFI in at least one instance and this is causing dead locks when used with log4rs. log4rs will spawn a thread to roll its file over as part of its rolling_file functionality. After the Rust runtime has called ExitProcess from Win32 the aforementioned wgpu FFI code is still running. However, Windows does not permit you to spawn a thread after ExitProcess has been called, so this log statement panics and hangs indefinitely.

Repro steps
Add log4rs logging using a rolling file appender to a wgpu program using only the DX12 backend, and set the size at which it rolls over to a very small size such that it is rolling over very often. Do not filter warn level logs from wgpu. Use the log_panics crate to log panics as well. Start and stop the program repeatedly. Eventually it should hang.
Attaching a debugger to it will reveal that it has hung due to a panic on a log statement behind FFI.

Expected vs observed behavior
I expected that wgpu would catch_unwind to catch any potential log panic, and then either do nothing, or abort.

Platform
Windows 11, wgpu 0.11, rustc 1.58.1

[cwfitzgerald]

This is also the case for at least GLES