Bind group layout dedup

[nical]

Checklist

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

Description

Currently wgpu-core implement bind group layout deduplication only when it creates its own resource IDs. In other words it works for wgpu but not in Firefox.

This PR bridges the gap by allowing an optional indirection in bind group layouts: each BGL may store an ID referring to its "deduplicated" BGL. The indirection ID is never set in wgpu (when the IDs are generated by wgpu core), so in this configuration the behavior is unchanged (the indirection ID is always None).

When referring to a BGL the rest of the code must make sure to follow the indirection. The exception is command buffer processing which is considered hot code and where we first validate against the provided BGL ID and only follow the indirection if the initial check failed.

The main pain point with this approach is the various places where wgpu-core manually updates reference counts: we have to be careful about following the indirection to track the right BGL. I suspect that arcanization makes this better but I haven't tried to rebase this on top of it yet.

On the plus side, the plumbing to enable the validation to follow the indirection will make it very easy to decorate validation errors with labels in a followup PR.

This is the main thing preventing bevy apps from running in Firefox.

Alternatives

Deduplication could be re-implemented in Firefox's DOM glue, however it has a few disadvantages:

• The deduplication logic would be duplicated.
• More importantly, Firefox's WebGPU DOM/IPC glue is currently very simple. It is mostly a bunch of proxies for the various objects created and manipulated by wgpu-core. If BGL deduplication was implemented there, these proxies would have to reimplement much of the lifetime tracking logic that is present in wgpu-core: bind groups and pipeline layouts must keep their layouts alive, pipelines must keep their pipeline layouts alive, etc. We would prefer to preserve the simplicity of these proxies.

Can we do better in the long run?

I hope so. In a potential future where wgpu-core generates its own IDs even when run in Firefox, everything could be simpler and most of what's in this PR would be unnecessary. We have been discussing this with @jimblandy our plans aren't very well formed and it is rather far down the priority list but I'll try to summarize that in another issue.

Testing

I added a test which actually only covers wgpu's default configuration and not the new code. It's a bit tedious to test that (Need to write the test against wgpu-core, add an identity factory, etc), however that code path is covered by the WebGPU CTS so regressions will be caught in Firefox's CI (with a delay unfortunately).

[kdashg]

Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1611425

[cwfitzgerald]

Code looks fine minus nit

Has been addressed

[gents83]

@nical correct me if I'm wrong - what you're trying to do here is to get a BGL that already exist if descriptor is the same or if you already have the id ?
It's not compatible with Arcanization so I'll have to reimplement it and I would like to be sure to understand it 👍

[nical]

@gents83 yes, BGLs may now conceptually hold a strong reference to another compatible BGL. They need to keep the BGL they point to alive so in terms of arcanization they probably need to hold an arc.