Simplify some code around buffer unmapping

[nical]

Connections

Another minor refactoring on the way towards #4787.

Description

Pre-arcanization we were holding locks a lot longer in wgpu-core, and had to hold off fireing the mapping callback until we'd let go of these locks. In other words we couldn't fire the mapping callback while we had access to the buffer because it was guarded by the hub's buffers lock.

Fast-forward today, arcanization made it so we only briefly take the lock while grabbing an arc to the buffer. There are very few locks that are held now so the code can be simplified.

Now the internal buffer.unmap() directly fire the callback in places that don't hold locks. No need to use buffer_unmap_inner and hold on to the callback. There is also some unnecessary block nesting that is removed.

This PR also makes it so buffer_drop just calls buffer.unmap() instead of calling buffer.destroy() when the reference count is 1. I don't know why it used to call destroy in that case, I am pretty sure it does not need to and a subsequent PR will make buffer.destroy likely to cause contention on the snatch lock so we won't want to call it accidentally in drop.

This also actually fixes a bug! In buffer_destroy we were holding the hub's buffer lock when calling buffer.destroy which unmapped and involed the callback. Oops!
To address this, the hub buffers lock is contained into a block and buffer.unmap() is lifted up closer to the api entry points in device/global.rs to avoid accidentally calling something that might call it whil holding a a lock.

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable
• Run cargo xtask test to run tests.

[cwfitzgerald]

Very nice code, I really appreciate the full write-up which allowed me to fully understand what was going on!.