Package all required components of the MinGW toolchain

[brson]

Easier than #9367. We're already packaging a few of MinGW's binaries. There are probably just a few more pieces needed to have a completely self contained toolchain. This will require either using the linker directly on windows or packaging all of gcc with Rust.

Nominating.

[pnkfelix]

Accepted for 1.0, assigning P-backcompat-libs (in lieu of P-backcompat-tools)

[brson]

May depend on #11937.

[brson]

My current opinion is that just bundling gcc is the path of least resistence here. gcc's dependencies are no greater than ld itself. The only sticking point is that gcc's license does include the GPL runtime exception, unlike the other components. I'm investigating the legal issues.

[thestinger]

I still think we would be better off bundling clang and using it to drive ld, because it would avoid spawning a large process. That's a significant cost on Windows slowing down every compile.

[brson]

Building clang is a possibility for the future but it is a bigger and more controversial change. Using clang to drive ld still requires bundling the GNU linker, so doesn't save us any appreciable amount of work. I would rather still just use lld directly, skipping clang entirely.

[thestinger]

The comparison would be pre-built clang (used as a library) vs. pre-built gcc. It could be built as part of building Rust but it's no more necessary than building gcc AFAICT.

[thestinger]

Well, I guess it does need to match the LLVM version.

[brson]

Still waiting on legal advice re packaging gcc.

[brson]

Packaging gcc is fine, considered 'aggregation' in GPL terms, which is allowed in most circumstances, including this one.

[brson]

Also need to package 'ar'.

[alexcrichton]

LLVM has an llvm-ar utility, and I believe that it encompasses all of our use cases, so it may not be strictly required in the long run to continue shelling out to ar, but for now I believe it's easiest to just bundle it.