Disable /analyze for libcxx

[StephanTLavavej]

While working on a compiler improvement that slightly increases compiler memory consumption, Jennifer Yao encountered a libcxx failure due to the x86-hosted compiler running out of memory. What was happening is that our use of /analyze in the libcxx test suite was causing a ranges test to consume a wild 3.34 GB, so any slight increase would push it over the edge.

To be a good kitty, I reported this as VSO-2576569 "/analyze consumes 13.9x more memory for a ranges algorithm test". And of course, x86-hosted tools in the year 2025 are an abomination, and it's bad and wrong that we're still shipping them. But as long as we do, we need to exercise them. (And also, switching over our internal test harness to use x64-hosted x86-targeting tools would be moderately obnoxious.)

Instead of skipping the affected test, or scouting for similarly memory-hungry tests, I rethought why we're using /analyze in libcxx in the first place. We pioneered aggressively using /analyze in the STL's test suites, and its usage in tests/std provides extremely valuable coverage. We run far fewer libcxx configurations (as libcxx has a ton of tests, every compiler configuration is very expensive), so we figured that we may as well add /analyze while we were at it. However, in addition to increasing test runtime (and compiler memory consumption!), this regularly causes headaches because libcxx developers naturally don't audit their tests with MSVC, much less MSVC /analyze, so we have to deal with warnings emitted by test code. And while this coverage has found a moderate number of compiler bugs in /analyze itself, it generally hasn't found unique problems in the STL which weren't found by tests/std already.

Finally, in the last year or two, MS has gotten significantly more serious about increasing /analyze adoption internally, with all of MSVC now routinely being built with /analyze. This means that the STL is being exercised far more widely with static analysis, and by realistic usage instead of the unusual patterns of a Standard Library test suite, so running it in the libcxx test suite is less important than it used to be.

This PR removes /analyze from libcxx and restores all of the tests we had knownfailed. On my 5950X, this results in a nice speedup, from 1590s (26m 30s) to 892s (14m 52s), a 1.78x speedup.

[StephanTLavavej]

Partially mirrored into prod/be with MSVC-PR-670705. I will still normally mirror this to prod/fe.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

I've pushed an additional commit to add an MSVC-internal skip. One of the tests that I was reactivating emits truncation warnings, which the GitHub harness knows how to silence, but not the internal harness.