Add hybrid/cooperate suspend runtime support on Windows.

[lateralusX]

Adding initial support for hybrid and cooperate suspend on Windows 32/64-bit platforms.

Fixes/adjustments needed in several areas:

Implementation/emulation of gcc's __builtin_unwind_init on MSVC needed by copy_stack_data function.

All wait methods have been extended with a cooperative alternative + handling interrupt under hybrid/cooperative suspend.

Methods that handles IO abort interruption on Windows (file, socket) have been updated to handle interrupt under hybrid/cooperative suspend.

Moved Windows implementations into w32handle.c instead of #ifdef on call site.

Reduced number of GC safe transition in a couple of Win32 file IO methods.

Added restore logic to Win32 last error when exiting GC safe mode. This is needed since we have code that depends on GetLastError that could be clobbered if exiting GC safe mode enter a wait. Also added last error restore logic to uninstall interrupt handler since it is commonly used right after exiting GC safe mode.

[jaykrell]

Nice overall, just nit picking.

[lateralusX]

First run all Windows configs have pass using default preemtive suspend. Next round will be hybrid suspend + review feedback.

[jaykrell]

Now just to add four or eight more CI lanes? :)

[jaykrell]

Again very good, I just nit-picky.
Putting explicit __cdecl on the x86 asm is maybe the only significant point.
The compiling mono with default __fastcall or __stdcall might be catastrophic in other places anyway.

[lateralusX]

First run of hybrid suspend on CI for all Windows configuration is done!

Windows x64, all CI test pass on hybrid suspend.
Windows x64 C++, all CI test pass on hybrid suspend.

Windows x64 FullAOT, only one failing test case, error in finalizer-exit:

finalizer-exit.exe
=============== finalizer-exit.exe.stdout ===============
Set ID: foo
finalizer thread ID: foo

=============== EOF ===============
=============== finalizer-exit.exe.stderr ===============

Windows i386, 3 failures, all looks related to the same issue:

MonoTests.runtime.thread-suspend-suspended.exe
MonoTests.test-sgen-regular-ms-simple.sgen-new-threads-collect.exe
MonoTests.test-sgen-regular-ms-simple.finalizer-wait.exe

Cannot transition thread 000001A8 from SELF_SUSPENDED with REQUEST_PULSE

[lateralusX]

Run with cooperate suspend on CI, all test pass.

[lateralusX]

Analyzed failure in thread-suspend-suspended.exe on 32-bit Windows and the identified problem, Cannot transition thread 000001A8 from SELF_SUSPENDED with REQUEST_PULSE, could happened in the following scenarion (emulated in debugger).

• Have main thread run its start_gc.Set () call but freeze before entering GC Safe of its next wait, finished_gc.WaitOne ()
• Run GC thread and let it do first phase, this will wait for main thread to suspend.
• Switch to main thread and resume it, this will make it self suspend on enter GC safe. NOTE, entering GC safe will call into OS WaitForSingleObject to wait for resume.
• GC thread will now look at the threads and determine if its in a critical region or not. On wow64 this means doing some extra check, mono_threads_platform_in_critical_region, that could fail, especially in hybrid suspend since we have not suspended the thread in the case (it's self suspended or on its way towards self suspend, but still running code).

If it fails due to that check stw will move over to pulse resume the thread but since it is already self suspend, it will hit the assert. The fix is to not do the wow64 critical check, mono_threads_platform_in_critical_region, if thread is not preemptive suspended. This is needed since the call to GetThreadContext is not guaranteed to get a valid context on a running thread.

[lateralusX]

Run with hybrid suspend on CI, all Windows test lanes pass.

[lateralusX]

@monojenkins rebuild failed