Improve error message when execution STATE is unavailable

[jamesbornholt]

A mistake we sometimes make when working on a large code base that uses Loom for testing is messing up our conditional imports, such that either a non-Loom-controlled std::thread is constructed or a Loom synchronization primitive is accessed from outside the context of a Loom model.

Here's a simple example distilled from one such mistake I made just now:

#[test]
fn thing() {
    loom::model(|| {
        let lock = Arc::new(Mutex::new(0));

        let thd = {
            let lock = lock.clone();
            // oops, wrong `thread`, not controlled by loom
            std::thread::spawn(move || {
                *lock.lock().unwrap() += 1;
            })
        };

        thd.join().unwrap();

        let lock = Arc::try_unwrap(lock).unwrap().into_inner().unwrap();
        assert_eq!(lock, 1);
    })
}

(Usually, the thread spawn happens in some other piece of code, so the problem is less easy to spot).

When this test fails, it gives a fairly opaque error message from Loom's internals:

thread '<unnamed>' panicked at 'cannot access a scoped thread local variable without calling `set` first', /Users/bornholt/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:168:9
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa/library/std/src/panicking.rs:543:12
   1: scoped_tls::ScopedKey<T>::with
             at /Users/bornholt/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:168:9
   2: loom::rt::scheduler::Scheduler::with_execution
             at ./src/rt/scheduler.rs:48:9
   3: loom::rt::execution
             at ./src/rt/mod.rs:156:5

This change just gives a more suggestive error message about what's going wrong:

thread '<unnamed>' panicked at 'cannot access Loom execution state from outside a Loom model. are you accessing a synchronization primitive from outside a Loom test (a call to `model` or `check`)?', src/rt/scheduler.rs:127:13
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa/library/std/src/panicking.rs:543:12
   1: loom::rt::scheduler::Scheduler::with_state
             at ./src/rt/scheduler.rs:127:13
   2: loom::rt::scheduler::Scheduler::with_execution
             at ./src/rt/scheduler.rs:48:9
   3: loom::rt::execution
             at ./src/rt/mod.rs:156:5

[hawkw]

looks good to me! one minor suggestion