Deadlocks possible with bad LockFor<L> impl

[jasper310899]

If you lock the same mutex twice from two different LockFor impls you can create a deadlock:

Therefore I propose that a derive macro replaces manual LockFor implementations making the abstraction perfect. LockFor should then become a unsafe trait.

[jasper310899]

Additionally I think we should make Locked::new() panicing if that thread already has a Locked object because currently this can also deadlock:

use lock_tree::{ lock::LockFor, relation::LockAfter, Locked, Unlocked};

#[derive(Default)]
struct HoldsLocks {
    a: Mutex<u8>,
}

enum LockA {}

impl LockFor<LockA> for HoldsLocks {
    type Data = u8;
    type Guard<'l> = std::sync::MutexGuard<'l, u8>
        where Self: 'l;
    fn lock(&self) -> Self::Guard<'_> {
        self.a.lock().unwrap()
    }
}

impl LockAfter<Unlocked> for LockA {}

fn main() {
    let state = HoldsLocks::default();
    let mut locked = Locked::new(&state);
    let (_a, _) = locked.lock_and::<LockA>();
    let mut locked = Locked::new(&state);
    let (_a, _) = locked.lock_and::<LockA>();
}```