Support building from a MinGW-w64-based compiler

[HertzDevil]

This is a continuation of #15070 that allows a compiler built with MinGW-w64 to itself build programs correctly. Resolves part of #6170.

• Because linker flags for GCC may now be executed on a Windows environment, we use the correct form of argument quoting. We also drop -rdynamic since that only makes sense for ELF executables.
• Targetting x86_64-windows-gnu, including normal compilations from such a Crystal compiler, will not copy dependent DLLs to the output directory. Crystal itself and programs built under MSYS2 will just work as long as the proper environment is used. You are on your own here, although ldd exists on MSYS2 so that you don't need the MSVC build tools for this.
• The correct GCC compiler flag to select wmain over main as the C entry point is -municode. (The system entry point is presumably _start now.)
• legacy_stdio_definitions.obj doesn't exist on MinGW-w64, so we disable it outside MSVC.
• For build command lines that are too long on Windows, we use GCC's response file support.

To build a MinGW-w64 compiler:

@REM on the MSVC developer prompt
make -fMakefile.win crystal
bin\crystal build --cross-compile --target=x86_64-windows-gnu src\compiler\crystal.cr -Dwithout_interpreter

# on MSYS2's UCRT64 environment
pacman -Sy \
  mingw-w64-ucrt-x86_64-gc mingw-w64-ucrt-x86_64-pcre2 mingw-w64-ucrt-x86_64-libiconv \
  mingw-w64-ucrt-x86_64-zlib mingw-w64-ucrt-x86_64-openssl mingw-w64-ucrt-x86_64-llvm
cc crystal.obj -o crystal \
  $(pkg-config bdw-gc libpcre2-8 iconv zlib openssl --libs) \
  $(llvm-config --libs --system-libs --ldflags) \
  -lDbgHelp -lole32 -lWS2_32
export CRYSTAL_PATH='lib;$ORIGIN\src'
export CRYSTAL_LIBRARY_PATH=''

Now you can run or build a considerable number of files from here, such as ./crystal.exe samples/2048.cr and ./crystal.exe spec spec/std/regex_spec.cr. Notable omissions are OpenSSL and LLVM, as fixing their version detection macros is a bit complicated.

The interpreter is not supported. Most likely, Crystal::Loader would have a GCC-style .parse, but the rest of the functionality would be identical to the MSVC LoadLibraryExW-based loader.

Also, some invocations like ./crystal.exe spec spec/std/json will fail since the whole command line string is too long. Similar to MSVC, GCC also handles response files starting with @, so this can be implemented later; a workaround is to use --single-module.

For reference, here are all the useful MSYS2 packages and their corresponding pkg-config names:

MSYS2 package name	pkg-config name
mingw-w64-ucrt-x86_64-gc	bdw-gc
mingw-w64-ucrt-x86_64-pcre2	libpcre2-8
mingw-w64-ucrt-x86_64-libiconv	iconv
mingw-w64-ucrt-x86_64-gmp	gmp
mingw-w64-ucrt-x86_64-zlib	zlib
mingw-w64-ucrt-x86_64-libxml2	libxml-2.0
mingw-w64-ucrt-x86_64-libyaml	yaml-0.1
mingw-w64-ucrt-x86_64-openssl	openssl
mingw-w64-ucrt-x86_64-libffi	libffi
mingw-w64-ucrt-x86_64-llvm	(use llvm-config instead)