Speed up UI tests

[LukeMathWalker]

We currently have ~140 different test projects, with the fastest platform taking almost 10 minutes to run the whole UI test suite. That's not sustainable.
This PR significantly restructures pavex_test_runner, the custom test harness used to write UI tests for Pavex.

The main obstacle is cargo's locking system—each test needs to compile some crates (the generated app, sometimes an integration test) as well as generate some JSON documentation via rustdoc. All these activities compete for the lock.

This PR rearchitects pavex_test_runner to minimise lock contention and maximise core usage.
In particular:

• All JSON docs are generated upfront, in batch, ensuring that each test hits the SQLite cache rather than invoking cargo directly, thus avoid contention;
• All UI tests now live in the same (separate) workspace, under ui_tests. They share a single target folder and their features are unified via a dedicated workspace hack crate. This ensures that we get full cache re-use across tests.
• All compilation jobs (e.g. generated apps or integration tests) are batched to maximise core utilisation

The speed-up has been substantial. In CI, we now run UI tests on Linux in ~7m compared to the ~11m we were seeing on main. The difference is even more extreme on Windows: from 16m to 9m. We also scored further wins there, by carving out some particularly slow tests, saving 5 minutes on executing unit tests.

Some leftover work to be done in followup PRs:

• Fix all warnings in UI test code
• Ensure that all test_config.toml files are only using valid keys
• Enforce programmatically the crate naming structure ({prefix}_{hash}) to avoid divergence over time
• Add utilities to generate the scaffolding for a new test

[LukeMathWalker]

/ok-to-test sha=7ea7aa7

[LukeMathWalker]

/ok-to-test sha=e248d9d

[LukeMathWalker]

/ok-to-test sha=e617916

[LukeMathWalker]

/ok-to-test sha=a14b195

[LukeMathWalker]

/ok-to-test sha=07a0248

[LukeMathWalker]

/ok-to-test sha=0bef47b