Setup `context.random_generator` in test runner

[Feoramund]

I've set it up so the test runner initiates the random generator now, so tests don't have to.

[Feoramund]

There's something to this Buggy_Struct test failure. It appeared on my fork's CI as well. I thought it initially to be a quirk of the GitHub process after checking for any rand procs in it, but now I'm not so sure.

[Feoramund]

I have a tentative fix for this, but I don't know why it works. I've been borrowing GitHub's CI to experiment with atomic changes on a separate branch to see what makes this bug arise, since I do not have access to a Windows machine.

The call to runtime.default_random_generator(&random_generator_state) is somehow causing this, because if I construct the generator in-place, Windows passes. I was also able to get it to pass by moving the RNG setup before the call to free_all.

Non-exhaustive list of other attempts at debugging this:

• Calling default_random_generator and assigning it to a temporary variable first before setting it on context.
• Performing the context assignment in an inner scope.
• Switching the calls in rtti_test from tprintf to aprintf just in case something odd was happening with the temporary allocator.
• Setting thread count to 1, just in case some other test was somehow corrupting the stack of the other test, as astronomically rare as that should be, if even possible.
• Making the test runner only test rtti_test. The bug still showed up, completely ruling out interference from other tests.
• Allocating a Default_Random_State on the heap instead of referencing the one on the stack.

I'm baffled as to why a contextless proc that merely returns a struct would somehow cause a misread failure in rtti_test. The misread is very consistent too. It's always c on the l_buggy Buggy_Struct that gets seemingly random data.

It's fixed now, at least. I'm quite curious why it was happening and wish I could attach a debugger to the Windows executable.