Deprecate msys in favor of standalone mingw64 builds.

[cheatfate]

Currently our CI environment is based on using msys building environment, but this become an issue in last few days.
Number of PRs got failed without any reasons:

• bearssl: use split ABI #282
• Token bucket #279
• AsyncEventQueue (AsyncEventBus replacement). #275

This happens because of some changes inside msys which we could not control. It could be gcc version or libgcc fixes.

To fix this in the future we should start using standalone mingw64 builds which could be found here https://winlibs.com/ . There some benefits.

1. We could control compiler version.
2. All the binaries hosted on github.
3. There is no hidden dependencies and there is no need to perform any installation. Unzip and use.

I still think that gcc-12.1.0 has some issues, so i will propose to stick with gcc-11.2.0, which i have been using for many months already.

[arnetheduck]

One thing to investigate with winlibs is its compatibility with libbacktrace - libbacktrace relies on DWARF symbol tables to generate call stacks - it shouldn't be a problem, but since winlibs uses SEH (and not DWARF) for its exception handling, it's worth taking a look.

"Native" / non-libbacktrace nim stacktraces are not a realistic option (ie 2-3x slower).

[cheatfate]

SEH and DWARF has only meaning for x86 and if you check winlibs you will find that on x86 it has DWARF suffix, also i have not found any issues/crashes while using this compiler for a long time.

The Dwarf-2 EH implementation for Windows is not designed at all to work under 64-bit Windows applications. In win32 mode, the exception unwind handler cannot propagate through non-dw2 aware code, this means that any exception going through any non-dw2 aware "foreign frames" code will fail, including Windows system DLLs and DLLs built with Visual Studio. Dwarf-2 unwinding code in gcc inspects the x86 unwinding assembly and is unable to proceed without other dwarf-2 unwind information.

The SetJump? LongJump? method of exception handling works for most cases on both win32 and win64, except for general protection faults. Structured exception handling support in gcc is being developed to overcome the weaknesses of dw2 and sjlj. On win64, the unwind-information are placed in xdata-section and there is the .pdata (function descriptor table) instead of the stack. For win32, the chain of handlers are on stack and need to be saved/restored by real executed code.

https://sourceforge.net/p/mingw-w64/wiki2/Exception%20Handling/

[cheatfate]

Also i want to put this information link here
https://wiki.qt.io/MinGW-64-bit

Which explains same things but from QT developers.

From this one i even see that we should deprecated posix threads in windows builds too.