ndk-glue: Switch to parking_lot for mappable and Sendable lock guards

[MarijnS95]

Depends on #282

It has come up previously that the native_window() function is easier to use if we could transpose a LockGuard<Option<>> into an Option<LockGuard<>>. After all, as soon as you have the lock you only need to check the Option<> value once and are thereafter guaranteed that its value won't change, until the lock is given up.

At the same time parking_lot has a send_guard feature which allows moving a lock guard to another thread (as long as deadlock_detection is disabled); a use case for this recently came up in glutin where the NativeWindow handle lock should be stored with a GL context so that our fn on_window_destroyed() callback doesn't return until after the Surface created on it is removed from the context and destroyed. Glutin forces this context to be Send, and a lock guard already allows Sync if NativeWindow is Sync (which it is).

[MarijnS95]

I mentioned in #285 that we can constly construct the RwLocks from parking_lot without Lazy wrapper, but that would bump our MSRV to Rust 1.61 (current stable as of writing): Amanieu/parking_lot#325.

Is that something we want to do or have hard feelings against? We never cared much about MSRV and I wouldn't even know where this crate (the chain of these crates) are at right now.

If we do, we should at least test the MSRV that we set in the CI and specify it in Cargo.toml so that users get a sensible error, rather than a mid-crate compiler error stating that these functions are not const.

---

EDIT: In case it isn't clear, I don't think we should bump MSRV purely to drop a few Lazy<> wrappers around RwLocks - but it is interesting to consider if we have to maintain an MSRV at all, and apply this whenever we need 1.61 as MSRV for other reasons :)