Fix mutex references and the global lock

[martin-hughes]

This fixes #305 by correcting the mutex acquisition and release. It also allows mutexes to be acquired and released by reference, since otherwise it is not possible to acquire (or release) _GL.

@IsaacWoods the main question I had was about where to keep track of the reentrant acquisition count of global_lock_mutex. Clearly the Handler should not release the actual mutex until the count reaches zero, but we don't know what the count is.

There were two options that I could think of:

1. Keep track of the count in Interpreter (which I chose), or
2. Require Handler to return a value indicating whether the mutex was fully released or not.

Option 2 would require an API change, and also relies on the implementer to correctly deal with reentrancy. Whereas option 1 allows the crate to deal with an inadequately implemented Handler but if Handler is wrong then the actual mutex may come out of sync with the firmware lock.

I would be happy to switch to option 2 if you prefer, Isaac.

[SnowCheetos]

Perhaps a syntax sugar closure like handler.with_lock(...) would a nice little addition to make life easier, smth like:

fn with_lock<R>(
    &self,
    mutex: Handle,
    timeout: u16,
    f: impl FnOnce() -> R,
) -> Result<R, AmlError> {
    self.acquire(mutex, timeout)?;

    struct Guard<'a, H: Handler> {
        handler: &'a H,
        mutex: Handle,
    }

    impl<H: Handler> Drop for Guard<'_, H> {
        fn drop(&mut self) {
            self.handler.release(self.mutex);
        }
    }

    let _guard = Guard {
        handler: self,
        mutex,
    };

    Ok(f())
}

Little helpers like this saved plenty of boot wedges for me

[martin-hughes]

Do you mean to add to this PR? If so would you show me an example of it being used?

I can think why it might be generally useful but I'm not sure about needing it here