Use Clang/lld for Windows toolchain

Recently msys2 started enabling ASLR support in its toolchain, uncovering a number of bugs in GHC's code generation strategy on Windows as well as bugs in upstream toolchain components (e.g. ld.bfd, see binutils #26757). This has rendered GHC completely unusable with recent msys2 toolchains (see #16780 (closed)).

Given that enabling ASLR is already quite a significant undertaking, I was originally reluctant to simultaneously change the toolchain as well.

Unfortunately the move away from gcc to clang was necessitated by the currently rather messy state of gcc and binutils on Windows. Specifically, ld.bfd produces broken output in links containing weak symbols when the image base is above 4GB (see binutils bug #26757). My initial thought was to work around this by moving to lld for linking but continuing to use gcc for compilation and gas for assembly. Unfortunately, this is precluded by a gas bug (see GHC #9907 (closed)) which causes it to produce ill-formed PE objects.

Consequently, we are are forced to move change our entire native toolchain. This, of course, comes with the potential for us to uncover new bugs in the new toolchain. On the other hand, it also has a number of up-sides:

• lld is considerably faster than ld.bfd, particularly on Windows (closing #16084 (closed))
• we no longer need the rather clever-but-hacky binary patching logic that we previously relied on to allow gcc to be long-file-path-aware. We previously considered switching to LLVM for this reason alone #17777 (closed))
• using LLVM end-to-end means that we avoid issues like #16354 (closed), where GHC's LLVM backend would produce assembly (via opt) that the gas assembler is unable to parse.