wait_timeout and friends shouldn't count as deadlocking

[jamesbornholt]

Shuttle complains that this test deadlocks, but in reality it doesn't:

#[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.