[llvm-lit] copy CRT/STL DLLs into the output directory

[strega-nil]

Summary

It turns out that the STL requires you to place the DLLs into the
directory of the executable; else, msvcp140.dll will be taken from
C:\Windows\System32 (which is unsupported).

This was discovered because of the recent constexpr mutex change;
see [microsoft/STL#3824][]. Especially the fuzzer unit tests fail
completely with the mutex changes.

[microsoft/STL#3824]: https://github.com/microsoft/STL/issues/3824

[strega-nil]

llvm/utils/lit/lit/TestRunner.py

2081 ↗

(On Diff #551284)

This doesn't work with clang's version of lit, only with our msvc version of lit, since the output directory is shared; I'm going to need to figure out a better way to do this, that works with either.

[strega-nil]

Fix the code to work with built-in lit/main.py

The code in the first commit was designed to work with MSVC's internal
lit/msvc_main.py; the new code works with either.

[strega-nil]

oops, missed a commit (ignore)

[rnk]

I'm not that familiar with the typical compatibility requirements for DLLs in the Windows system folder, but it seems pretty disruptive to ship a DLL in the system folder, and then ship ABI incompatible changes without increasing the version number. Wouldn't this all work if the STL increased the version number of msvcp140.dll instead?

llvm/utils/lit/lit/run.py

73

This is typically quite a lot of directories, so this doesn't seem like a great solution. I looked at the DLL search path docs, and it looks like the system directory (C:\Windows\System32) precedes PATH, which is unfortunate. Is there no other way to inject a DLL search path *before* the system directory? SxS manifests seem like the most promising option, but that doesn't sound like fun either.

[strega-nil]

It turns out I misunderstood how this release process works; it is _only_ important inside our internal test harness, not inside the LLVM public test harness; I apologize for opening this non-useful PR.