`wait_timeout` and friends shouldn't count as deadlocking

Shuttle complains that this test deadlocks, but in reality it doesn't:
```rust
#[test]
fn wait_timeout_deadlock() {
check_dfs(
|| {
let lock = Arc::new(Mutex::new(false));
let cond = Arc::new(Condvar::new());

let guard = lock.lock().unwrap();
let (_guard, result) = cond.wait_timeout(guard, Duration::from_secs(1)).unwrap();
assert!(result.timed_out());
},
None,
)
}
```
The problem is that, while `wait_timeout` _temporarily_ blocks the thread, it's not permanent, and so shouldn't count as deadlock.

We already knew that our modeling of `wait_timeout` wasn't complete because it doesn't test the timeout case, but this test shows the effects of such incompleteness—spurious failures.

We need to have a better notion of "blocked but can be unblocked". One cheap-ish idea would be for `wait_timeout` to spawn another (internal to Shuttle) "thread" that, when executed, causes the thread blocked in `wait_timeout` to unblock and return timeout. This would let the scheduler "naturally" decide when to trigger a timeout rather than us having to build any fancy time handling into the scheduler itself.

Start with the shown wait_timeout_deadlock test and trace the wait_timeout modeling used by check_dfs. Investigate how Shuttle distinguishes permanently blocked threads from operations that can later unblock, then define a scheduler-visible timeout behavior and verify that the test no longer reports a deadlock while still checking the timeout result.

Written by the indexing model from the issue text.