Idea: deterministic thread and I/O handling for certain tests

For testing, e.g. with Hypothesis, it can often be useful to run deterministically even at the cost of performance.

Using a MockClock(rate=0, autojump_threshold=0) and setting _ALLOW_DETERMINISTIC_SCHEDULING=True does the trick for tests that only use in-process Trio interfaces, but if you need to test with real network IO or multiple threads, then the variation in timing can change which tasks can be scheduled at each point, and we're nondeterministic again.

I recently saw a neat proof-of-concept that gets around this: whenever you would do real IO (i.e. not controlled by the MockClock), do the real IO but don't let reality control the timing. Instead, use the PRNG to choose how long that operation will take - if it finishes earlier, hold it until the chosen time; if it's not ready by then hold the rest of the program (including the clock) until the operation finishes.

Brief notes:

• I think we'd want to patch trio.to_thread.run_sync, trio.from_thread.run, trio.from_thread.run_sync, trio.serve_listeners, trio.open_tcp_stream, trio.lowlevel.wait_readable, trio.lowlevel.wait_writable, and trio.open_signal_receiver to support this where possible, or explicitly error out otherwise.
• It might also be interesting to automatically use an in-process network when a client and server are in the same process, instead of going over real OS sockets. This is very convenient but also I dislike silently testing something other than what the user expects.
• I think this is too big a change to automatically activate whenever there's a suitable clock and deterministic scheduling is enabled, so we'll want some way to explicitly turn it on, too.

I'm not fully convinced that we should ship something like this, but it seems interesting enough to write up and investigate futher.

Start with the deterministic scheduling setup described in the issue: MockClock, _ALLOW_DETERMINISTIC_SCHEDULING in src/trio/_core/_run.py, and the listed thread, socket, signal, and low-level I/O APIs. Investigate how real I/O timing could be controlled across these entry points, including the in-process network idea. Done would require a decided scope and explicit activation behavior, but the issue does not define an implementation plan or acceptance tests.