`wgpu-core` contains deadlocks

[jimblandy]

In the process of developing #5539, we identified at least one deadlock in wgpu-core, and I suspect there are others. We should fix these deadlocks, updating lock::rank as we go, and enable the lock::ranked run-time validation by default in debug builds (#5937).

The presence of deadlocks means that no cycle-free ranking of locks exists that won't cause panics in our current tests and examples. This means that the ranking defined in lock::rank must either remain incomplete, or we should change the implementation to permit ranking cycles for the time being. The latter option is unappealing, so we plan to land #5539 with an incomplete ranking, meaning that enabling the validate-locks feature will cause panics for now.

Issues for specific deadlocks:

• [core] deadlock between adapter_request_device and device_poll #5807
• [core] Deadlock involving five locks #5583
• [core] Deadlock involving three locks #5592
• Deadlock in 0.20.0 and trunk #5662
• [core] deadlock between poll_all_devices and queue_submit #5695
• [core] Deadlock between device.tracker and device.snatchable_lock #5737
• [core] Deadlock between Device::temp_suspected and CommandBuffer::data #5647
• thread 'main' attempted to acquire a snatch lock recursively #6378
• wgpu Deadlock #6412
• Deadlock between queue submission and buffer destruction #7254