Expose a lock which doesn't get poisoned on panic

[sarsko]

We need this to fix the parking_lot primitives.

Currently they can panic due to the backing primitive becoming poisoned.

My initial thought was to use clear_poison #233, but this is not robust, as the following scheme

lock.clear_poison();
lock.lock().unwrap();

Runs into the issue that the lock holder may panic after the poison has been cleared, and a scheme of the sort:

match lock.lock() {
    Ok(v) => v,
    Err(_e) => {
         lock.clear_poison();
         self.lock()
    }
}

Runs into the issue of a single lock becoming multiple yield points.

Either the shuttle-parking_lot primitives have to be built upon something else, or Shuttle has to provide a lock acquire without a scheduling point, or offer locking primitives which don't panic.

An alternative here is to not back Shuttle Mutex/RwLock on std Mutex/RwLock (or to provide a way to back them on something else), thought currently doing it like this gives us poison modeling which is convenient.