Use new runner for testsuite

[jdetter]

Description of Changes

Speed improvements:

CI Job	Before	After	Change
CI/Unreal Engine	29m	19m	34% faster
CI/Testsuite	21m	11m	47% faster
C#/Unity	20m	16m	20% faster
CI/Build and test wasm bindings	10m	3m	70% faster
CI/Smoketests (linux)	17m	12m	29% faster

CI/Unreal Engine - switch to serial test execution
CI/Testsuite - partially switch to serial test execution

I also haven't seen an unexpected Operation cancelled, so I think that problem might be behind us.

API and ABI breaking changes

No user facing changes

Expected complexity level and risk

2 - this touches a lot of our CI. It has been solid so far but if we start getting random CI failures this could be the cause.

Testing

• All CI passes

(ok as of this update the internal tests are failing but that isn't related to this PR 😅 )

Future Work

There are 2 remaining tests that could be optimized by moving them to faster runners:

1. (~45m) The windows smoketests (difficult because it requires Windows). @bfops has brought up the idea of only running this test on PRs that are in the merge queue and I think that would be the best 80/20 here. There really is not a great reason to be running this on every commit anyway.
2. (36m) The internal tests (easier because it's on Linux)

I would also consider moving from instantiating container images to instantiating VM snapshots. This would allow us a lot more flexibility and we wouldn't have to have as much container config in our workflow files. Based on guides I've seen online this is also somewhat common. Also managing docker within docker has been kind of a nightmare so it would be easier to run containers inside of VMs to remove a layer of containerization there.

Testsuite inconsistencies

We have at least 2 different jobs that are inconsistent/flaky: the "testsuite" and the "unreal engine tests".

I'd like @JasonAtClockwork to make the unreal engine tests run sequentially so that we have less random failures. I know this will increase the testing time but due to this PR we should have extra headroom there.

I've also pinged Joshua about one of the tests that I've seen sometimes fails randomly. This is either an issue in the test or an issue in SpacetimeDB itself, I'm not sure yet.

These inconsistencies are present both in our custom runner and in the Github runners, so merging this PR will not make this situation any worse than it already is.

[bfops]

this LGTM, though I worry about you being the only person who understands these changes. If something went wrong, I wouldn't know how to debug it.