This fixes multiple issues with random generators, with the most
important one being that multiple nested generators could return
values from the same sequence, due to internal implementation
details of `GENERATE`, and how they interact with test case
paths.

The cost of doing this is that given this simple `TEST_CASE`,
```cpp
TEST_CASE("foo") {
    auto i = GENERATE(take(10, random(0, 100));
    SECTION("A") {
        auto j = GENERATE(take(10, random(0, 100));
    }
    SECTION("B") {
        auto k = GENERATE(take(10, random(0, 100));
    }
}
```

`k` will have different values between running the test as
a whole, e.g. with `./tests "foo"`, and running only the "B"
section with `./tests "foo" -c "B"`.

I consider this an acceptable cost, because the only alternative
would be very messy to implement, and add a lot of brittle and
complex code for relatively little benefit.

If this calculation changes, we will need to instead walk
the current tracker tree whenever a random generator is being
constructed, check for random generators on the path to root,
and take a seed from them.

This is a necessary step to fix issue with combining multiple
random generators in one test case, with different section nesting.

We no longer use `std::rand` anywhere, so there is no point,
and it might even interfere with our users use of `std::(s)rand`.

This might become potentially useful in the future, when we want
to provide the ability to forward jump generators, to be able to
simply reproduce specific input to a test.

I am not yet sure how it would work, but the basic idea is that
it could be similar to the `-c` switch for selecting specific
`SECTION` in a test case.

The old instruction would cause the debugger to be stuck at the
triggering source line forever, while the new one should have the
expected semantics, where the debugger can then single-step,
continue. or generally do things, afterwards.

Closes #2422