Clean up i686-{pc, w64}-mingw32 triples

[klutzy]

We have two distinct triples: i686-pc-mingw32 (mingw) and i686-w64-ming32 (mingw-w64). However, there seems no need to maintain two triples separately, and even buildbots actually have used i686-pc-mingw32 on mingw-w64 without any issues.
There are some minor differences in mk/platform.mk (e.g. i686-w64-mingw32 doesn't fix mingw-specific problems) but they are mergeable.

The easiest fix is just to remove i686-w64-mingw32, and maybe some "redirection" (configure automatically converts i686-w64-mingw32 into i686-pc-mingw32) might be good too.

(Recently llvm cleaned up windows triples: the two triples are now canonicalized as i686-pc-windows-gnu.)

[brson]

I want to get this cleanup up for 1.0. It affects the name of the download artefacts we present, which ideally shouldn't change immediately after launch.

[pnkfelix]

Categorizing as P-high, not a 1.0 blocker.

[brson]

I wonder if old LLVM's understand the new canonicalized triples or if we might need to 'uncanonicalize' them before passing them on.

[brson]

The in-tree LLVM does not understand x86_64-pc-windows-gnu.

[brson]

Should we switch to the canonical triples anyway and decanonicalize for LLVM?

cc @cmr

[brson]

@sunfishcode suggests we get on board the canonical triple train and decononicalize for LLVM.

[brson]

In fact, it appears to only be the in-tree LLVM configure script that doesn't understand the new windows trips.

[emberian]

Yes. My target spec patch fixes this, actually.

[brson]

@cmr Do you want me to wait for you to land your patch?

[vadimcn]

@brson, we got canonical triples figured out in @cmr's flex target branch. And yes, in order to build LLVM and other deps, we have to pass them the old triple: https://github.com/cmr/rust/commit/bac1b460519319cff4095d87253439f10e17bb16

[alexcrichton]

Done!

[alexcrichton]

As in, @cmr's target customization branch landed the renaming to arch-pc-windows-gnu