[GCCToolchain] Add native Windows toolchains (i686, x86_64)

[maleadt]

This adds i686-w64-mingw32 and x86_64-w64-mingw32 to GCCToolchain. Each is a
native Windows GCC 15.2 with binutils 2.45.1, cross-built by the GCCBootstrap shard
compilers from the shards' own sources, patches and configuration (--disable-tls,
posix threads, libgomp). It is the same toolchain CompilerSupportLibraries 1.5.7 was
built with, so code compiled with it (or against its headers and import libraries)
matches the runtime Julia ships. MSYS2's GCC 16 does not: its libstdc++ uses a TLS
std::call_once ABI and its winpthreads headers call *64 functions, and neither
exists in CSL's DLLs.

Uses:

• Julia's optimized Windows builds point Clang_jll at it (--sysroot), which avoids
  the std::__get_once_callable() link errors of Windows: build in rootfs-images v8.10 (GCC 15.2), add scheduled optimized builds JuliaCI/julia-buildkite#636.
• PackageCompiler.jl can use it instead of its mingw-builds GCC 14.2 artifact.
• Julia's regular Windows builds could use it instead of MSYS2's GCC (as Linux CI
  does with the Linux platforms since rootfs-images v8.8).

Windows-specific choices:

• GCC's default MinGW layout, <sysroot>/mingw/{include,lib}. The recipe skips
  GCCBootstrap's layout-only gcc1520_mingw_include.patch; the other patches still
  apply. Clang's MinGW driver finds this layout when given the installation root as
  --sysroot, with no extra flags.
• The host executables and the LTO plugin are linked with --static, so they do not
  depend on whichever libstdc++/libwinpthread DLLs come first in the search path.
  (-static-libstdc++ ends in -Bdynamic before the driver's -lpthread, and libtool
  treats -static as "static libraries only".)
• Programs are installed without a target prefix (gcc.exe, plus cc.exe), as in
  other native MinGW toolchains. The <triplet>-gcc.exe aliases that clang searches
  for are kept.
• The runtime DLLs are in bin/.
• The build fails if libstdc++'s c++config.h differs from the shard's, if a host
  executable or plugin imports anything but system DLLs, or if the prefix contains
  symbolic links.

Checked:

• The exports of all eight runtime DLLs (libstdc++-6, libgcc_s_seh-1/_sjlj-1,
  libwinpthread-1, libgfortran-5, libquadmath-0, libgomp-1, libssp-0,
  libatomic-1) are identical to CSL 1.5.7's, with one exception: the i686
  libstdc++-6.dll also exports std::ios_base_library_init(), from
  gcc1520-libstdcxx-mingw-ios-init-export.patch. <iostream> only references it on
  ELF.
• On x86_64, the C++ and MinGW header trees and all CRT libraries and objects are
  byte-identical to the shard's.
• In a Windows Server 2022 VM:
  • g++ builds and runs C++20 code (call_once, threads, counting_semaphore), and
    windres works.
  • Clang 22 with --sysroot=<root> links against it, with ThinLTO and
    -fprofile-generate, using the non-TLS call_once ABI.
  • PackageCompiler (create_sysimage, create_app of its MyApp example) works with
    its mingw-w64 artifact overridden by this toolchain.
  • A full optimized (PGO+ThinLTO) Julia build succeeds in Julia's CI image
    (package-windows-x86_64:v8.5) with this toolchain first on PATH. Every
    runtime import in the result resolves against CSL's DLLs, and the shipped DLLs
    are CSL's.

Note for i686 clang users: this toolchain uses SJLJ exceptions (as CSL does), so
clang needs -fsjlj-exceptions. Clang defaults to DWARF on i686 MinGW.