Add MappedArcMutexGuard to mirror MappedMutexGuard

[dflemstr]

Add a new type, MappedArcMutexGuard, that mirrors the API of MappedMutexGuard but with an owned Arc<> reference to the underlying mutex while locked.

I didn't find any tests covering MappedMutexGuard, so I didn't change the status quo. Instead, I copied the exact same implementation as for MappedMutexGuard but with lifetimes removed and &'a R references to the raw mutex replaced with Arc<Mutex<T, R>>. I believe this should make the new type at least as sound as the previous MappedMutexGuard.

Unfortunately, since we only have an Arc around Mutex, but not the raw mutex type R, we cannot type erase the wrapped mutex and need to retain the original type T in MappedArcMutexGuard<R, T, U> (as opposed to MappedArcMutexGuard<R, U>).

The name was chosen based on the existing pattern of MappedFairMutexGuard to arrive at MappedArcMutexGuard (as opposed to e.g. ArcMappedMutexGuard or whatever).

[dflemstr]

I'm going to iterate a bit on the implementation of this PR and test it in various tricky production cases to make sure it is sound, so moving into Draft state

[dflemstr]

Gonna do some more testing but I think this PR is ready to get new eyes on it.

[Amanieu]

Unfortunately I don't think there is much value in adding this without support for type erasure, which is really the main selling point of MappedMutexGuard. Perhaps it would be possible to do something based on triomphe once #454 lands?

[gyscos]

I suspect there is a significant use for MappedMutexGuard (and an Arc version) beyond type erasure. Even when the inner type is public, the "mapping" function used might not, or might not be trivial enough to do on the consumer side.

Also, couldn't we get type erasure here? What does triomphe bring to make it easier?
If the MappedArcMutexGuard holds:

• AnBox<dyn Any> (or something similar) holding the Arc to make sure it still exists (and is refcounted down when dropped), but can be stored type-erased.
• A (type erased) raw mutex, similar to MappedMutexGuard. Could be a &'static R since we know the Mutex in the Arc above cannot move?
• The data itself (unchanged from this PR).

The main risk here is the "lie" in &'static R, which is the usual caveat with self-referencing structs. I think it's sound as long as the stored (and untouched) Arc<Mutex<R, T>> ensures that:

• The Mutex<R, T> still lives at the same memory address.
• The inner Mutex::raw therefore still lives at the same memory address.

There's just minor details regarding the Box<dyn Any> - to be cloneable, we'd rely on a local trait like

use alloc::boxed::Box;

trait AnyCloneable {
    fn any_clone(&self) -> Box<dyn AnyCloneable>;
}

impl <T: Clone> AnyCloneable for T {
    fn any_clone(&self) -> Box<dyn AnyCloneable> {
        Box::new(self.clone())
    }
}

And store a mutex: Box<dyn AnyCloneable>.

EDIT: I tried that, and it looks like it's working. Sent a PR with the experiment. Feel free to bash it if we don't want any of that.