Cesium tests are slower in Rider because they leak processes

From the very beginning of Cesium, I was quite puzzled why our tests are so slow in Rider.

And it seems I am beginning to understand it, finally.

Several times during today's full test run session, I've observed the same dubious pattern: a test runs, then a process leaks out of it (this is Windows, mind you). E.g. a stale MSBuild node, or a `vctip.exe`.

Rider test runner then gets stuck — it waits for this process to terminate, which they usually do with some degree of deliberation. Rider won't start a new test process until all the processes inside of the current run are terminated. It can wait for minutes or even indefinitely at times.

I'm not sure what tests these are exactly, though from what I see, at least the C compilation tests cause some problems (`vctip.exe` is part of the VS' C/C++ SDK). So, perhaps this is about the integration tests, mostly?

We need to make sure our tests are max hygienic and do not leave any stale processes after them — but at the same time, they of course shouldn't affect anything outside of their execution bubble.

Let's consider using job objects to run processes on Windows, and find out if this is at all a problem on macOS/Linux.