Batch RECTESTS into one process

[Nopey]

All 60 rectests are now executed in a single process.

Benchmarks (msvc debug builds on windows with address sanitizer):

4m9.633s (master)
1m18.524s (master, but with --warp turned on)
0m25.373s (this branch, running all the RECs in series)

As an added bonus, running all 60 rectests in series is enough frames to quickly exhaust our renderer atlas:

[Nopey]

timings in CI:
master: 3m 47s (6m 30s incl. build, menu tests, etc..)
this branch: 31s (5m 1s incl build, menu tests, etc..)

[Vagabond]

I don't think we should run with --warp. --warp skips ticks (IIRC), which is why we have not used it to run rectests before (I added --warp to the CLI so I could run rectests faster, until I discovered this problem).

[Vagabond]

I dislike losing the rectest description as a side effect here, the description was very handy in quickly understanding what you broke when you started to see rectests fail.

[Nopey]

Would you mind if we embedded them in the .REC files as some sort of comment?
Then the rec controller can find them when an assert fails

[Vagabond]

maybe? or just have a lookup table we can use to print a better description on a failure?

[Vagabond]

I'm not sure we have room for an artitrary string in the REC

[Nopey]

i was thinking add another "move" that's just a comment about what we're about to test.
when the rec fails, the rec controller would rewind looking for the last rec test comment & print it (again).

or we'll do a lookup table as you suggest, have that loaded from a .txt file in the rectests folder

[Nopey]

warp runs every dynamic tick.
the timing between dynamic ticks and static ticks is not guaranteed (on any speed).

if warp skips any dynamic ticks, that's a bug.

[Vagabond]

I believe warp IS buggy, but I don't have i

warp runs every dynamic tick. the timing between dynamic ticks and static ticks is not guaranteed (on any speed).

if warp skips any dynamic ticks, that's a bug.

I believe warp IS buggy, I just can't prove it.