Further troubleshoot why the first unittest to run on a new VM can take longer than it should

[paulcallen]

RE: #1313
During the investigations of a flakey unittest during pr #1313 it was discovered that the very first unittest to run on a new CI image in the PR pipeline this test would often take significantly longer than it should. The test/fork tests have 3 build dependencies for running tests. The first has three tests within it. These three tests are more or less doing the same thing, just testing very minor variances. The test itself calls a syscall that is disabled and so the test should get an error. The first test, however, could take sometimes many minutes to run where the other two complete very quickly. All three should take the same amount of time.
Investigations were done such that it was discovered the hanging was taking place even before the main() function in the myst tool itself was executed.
The script/runtest script does multiple things before finally executing myst, launching it through the timeout command in case it hangs. Sometimes this would generate a timeout and fail as a result of the timeout command.
With the script executing and the main() function not getting executed the only conclusion so far is that something during the CRT initialization is hanging. This initialization can include the initialization of any shared libraries and any global C++ constructors getting executed. No such initializations happen within the myst tool itself, so it can only be assumed that something is hanging within either a shared library that is being pulled in or a static library that is being linked.
The PR itself just increases the timeout of the very first test to allow more time for the unknown pause at the start to continue.
This issue is to try and track down further what is actually causing the pause so the underlying problem can be solved.