[Bug] Windows CI segfaulting during tests

[cretz]

Describe the bug

Looking at CI for Windows, segfaults are continuously occurring during the test portion and it is not known why. This could be related to running the dev server in a mssy2/mingw environment and not Ruby, unsure. Investigate.

[cretz]

So I have some backtraces from gdb like:

#0  0x00007ffcc22b7618 in x64-ucrt-ruby330!rb_w32_Sleep () from c:\dls\ruby-3.3.5\bin\x64-ucrt-ruby330.dll
#1  0x00007ffcb14fc9a2 in parking_lot::raw_mutex::RawMutex::lock_slow () from c:\work\tem\sdk-ruby\temporal-sdk-ruby\temporalio\lib\temporalio\internal\bridge\temporalio_bridge.so
#2  0x00007ffcb14e3568 in tokio::runtime::blocking::pool::Inner::run () from c:\work\tem\sdk-ruby\temporal-sdk-ruby\temporalio\lib\temporalio\internal\bridge\temporalio_bridge.so
#3  0x00007ffcb14a3b0a in std::sys::backtrace::__rust_begin_short_backtrace () from c:\work\tem\sdk-ruby\temporal-sdk-ruby\temporalio\lib\temporalio\internal\bridge\temporalio_bridge.so
#4  0x00007ffcb14c4d3f in core::ops::function::FnOnce::call_once{{vtable.shim}} () from c:\work\tem\sdk-ruby\temporal-sdk-ruby\temporalio\lib\temporalio\internal\bridge\temporalio_bridge.so
#5  0x00007ffcb1620a5d in std::sys::pal::windows::thread::Thread::new::thread_start () from c:\work\tem\sdk-ruby\temporal-sdk-ruby\temporalio\lib\temporalio\internal\bridge\temporalio_bridge.so
#6  0x00007ffd6078257d in KERNEL32!BaseThreadInitThunk () from C:\windows\System32\kernel32.dll
#7  0x00007ffd61e4af28 in ntdll!RtlUserThreadStart () from C:\windows\SYSTEM32\ntdll.dll
#8  0x0000000000000000 in ?? ()

Similar shown here when I turn on debug symbols. Basically it looks like somehow parking_lot::raw_mutex::RawMutex::lock_slow is calling rb_w32_Sleep which is so strange. I would expect rb_w32_Sleep to segfault if called from a non-Ruby thread (it asks for Ruby thread local info using TlsGetValue and always assumes that returns a non-null pointer, but in this case it is a null pointer). I wonder if somehow https://github.com/Amanieu/parking_lot/blob/0.12.3/core/src/thread_parker/windows/bindings.rs#L31 is actually picking up https://github.com/ruby/ruby/blob/v3_3_5/include/ruby/win32.h#L159 due to how the build is working that is putting Ruby headers on the gcc path or included alongside the Rust code. Very confusing.