fix(vulkan): Make error_if_would_oom_on_resource_allocation more accurate

[andyleiserson]

Connections
Alternative to #9359.
Fixes #8479.
Fixes #9206.

May fix some Firefox bugs that manifest as a dubious OOM error.

Description
Similar to #9359, but instead of checking all matching heaps, tries to replicate the logic that gpu-allocator uses to decide which heap to use for the allocation.

This is fragile when gpu-allocator changes. Some other strategies we could pursue:

• Don't try to proactively detect that an allocation will put us close to OOM, just try the allocation. Optionally, we could check heap usage after the allocation and abandon if it's too high.
• Ask for a change in gpu-allocator along the lines of this PR, to reduce the risk of drift.

Since allocations are made locally by gpu-allocator from memory blocks provided by the device, it's possible that (1) rejecting an allocation based on our OOM detection logic may not actually change the amount of memory available to other users of the GPU, (2) an allocation that our logic says will not produce an OOM causes a new memory block to be allocated, consuming more memory than the nominal amount of the allocation, resulting in OOM.

CC @jimblandy since we talked about this earlier.

Testing
Fixes various CTS failures on GPUs with multiple heaps. (Resolving some failures requires additionally setting MemoryHints::MemoryUsage, which I haven't done in this change.)

Squash or Rebase? Squash

Checklist

• I self-reviewed and fully understand this PR.
• WebGPU implementations built with wgpu may be affected behaviorally.
• Validation and feature gates are in place to confine behavioral changes.
• Tests demonstrate the validation and altered logic works.
• CHANGELOG.md entries for the user-facing effects of this change are present.
  • Missed when initially merged; added in docs(CHANGELOG): Add changelog entry for Vulkan OOM fixes #9768.
• The PR is minimal, and doesn't make sense to land as multiple PRs.
• Commits are logically scoped and individually reviewable.
• The PR description has enough context to understand the motivation and solution implemented.

[teoxoy]

Looks good, I imagined the logic would have been even more involved but it's not too bad. I also think it's unlikely to change and in the future we can still replace the allocator with our own custom implementation and have control over the logic.