Make some errors not fatal

[nical]

Checklist

• Run cargo clippy.
• Add change to CHANGELOG.md. See simple instructions inside file.

Connections

https://bugzilla.mozilla.org/show_bug.cgi?id=1791881

Description

Objects can be created with invalid parameters, putting them in an error state. When interacting with these objects, in the majority of cases validation should fail but wgpu should not panic.
buffer_get_mapped_range is one of these exceptions because the API user must not call it without getting consent from the status provided in the map_async callback.

Currently wgpu does panic when interacting with invalid resources in a few places and this PR starts fixing that. I did not go over all of them to make sure there is consensus before producing a large-ish patch, and to get the few changes needed to unblock fuzzing as soon as possible.

There two important changes in this patch:

• in hub.rs, Some(vacant) and None are the same (it indicates the resource was not created or was already dropped) so they should both be fatal errors.
• with the non-existent-or-freed error case out of the way, most places that call handle_error_fatal in backend/direct.rs should actually push the error into the error sink intsead of panicking.

Only the first change really affects Firefox, but I think that the second one better matches the spec and how Firefox uses wgpu-core.

Testing

Tests! I did it again.

[cwfitzgerald]

Tests make me very happy

[nical]

I updated the patch. fail can return values and is hoisted in common, there's a valid equivalent that asserts validation succeeded (useful when you want to assert that specific/individual calls pass validation).

I made a notable change to the error handling after checking the spec: buffer/texture.destroy does not actually raise any error even when called multiple times.

[cwfitzgerald]

Format mad, but otherwise LGTM