Add a "stress test" project that includes every single cppwinrt header that comes from the Windows SDK

[dmachaj]

(I'm going to let this build once to see if the build agent fails with out of memory errors, which they probably will, and then I will close it without merging)

I was hoping to crank up the warning and code analysis levels in this project to try and detect the issue that I fixed yesterday (see #1455). The goal being to detect as much as possible in this project in the hopes that we can rely less heavily on large consuming projects to detect compatibility and correctness issues. This project also has the Code Analysis level cranked up to the max to discover as much as possible (although most of the above-recommended warnings are incredibly noisy and uninteresting).

Unfortunately, I was not able to detect yesterday's issue using this approach. The reason why is that the issue fell within an "if constexpr" block that needs to become active for the warning to become visible. The only way to have the compiler discover the break is to activate that block, which requires consuming code. And not just any consuming code, but code that has to QueryInterface as part of the call. That seems impractical to generate on a large scale.

Nonetheless there may be some value in maintaining a project like this. This project provides us with two things that we didn't have before. First, it demonstrates that every single generated header in the Windows.* namespace compiles (minus unreachable if constexpr cases). Second, it provides a testbed for compiler speed, memory usage, and binary size. If someone decides to make a push to make cppwinrt generated code compile faster then traces from this stress test project would be helpful as an extreme case.

If we do want to try and merge this PR after all then the pch generation logic will need to be made more robust. It is not incremental build friendly and often hits "file in use" problems. It would maybe be appropriate to just check in the result and then regenerate it on an as-needed basis to keep things simpler.

[dmachaj]

Yep, fails to build (as expected). A few hit the aformentioned "file in use" error generating the huge pch.h. The rest hit either disk or memory exhaustion issues and failed.

[sylveon]

FWIW, once module support actually happens (still waiting on compiler bug fixes), this scenario will be exercised by a normal build, as doing import winrt would compile everything. It wouldn't hit memory exhaustion issues either because every module fragment gets its own compiler instance.