[core] make wgc::RenderBundleEncoder like Passes (with methods on self and global)

[sagudev]

Connections
As announced in #5121 (comment)

Description

Recording in content process must go and so does current form of RenderBundleEncoder, but before we start doing internal changes to the encoder itself let's make it's outside interface (that is from wgc, normal wgpu wraps it so there is no changes on the outside) same as of other passes with methods on both &mut self and Global (taking &mut RenderBundleEncoder as in passes, tho this might change in the follow ups). We still keep bundle_ffi for now (so there is less rush for changes in FF) but we do not use them in deno nor in wgpu anymore (less unsafe 🎉).

Testing

Mainly just refactor.

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.
• 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.

[sagudev]

cc @teoxoy

[teoxoy]

The 2nd and 3rd commits look good, but do we need the 1st? I think if we do we should at least make sure to panic if finish is called multiple times. At lest until we wrap the encoder's inner state into a Mutex and do the required validation.

[sagudev]

The 2nd and 3rd commits look good, but do we need the 1st? I think if we do we should at least make sure to panic if finish is called multiple times. At lest until we wrap the encoder's inner state into a Mutex and do the required validation.

Not really but the idea is that the API is done so we can do further internal changes without changing API. Should I drop it or fix it?

[teoxoy]

I think we still need changes to the API because right now all the functions take &mut RenderBundleEncoder which will have to be replaced with id::RenderBundleEncoder (same for render/compute passes). At least for Firefox we can't move onto the new API unless we move all encoder recording out of the content process and we can't do that unless the encoder creation methods can create the encoders with an ID + all the encoder methods take IDs. In the meantime we might be able to get away with some sort of 2nd Registry for encoders but that seems like it's more effort than it's worth.

I think we should drop the 1st commit and move it into the PR that does the more extensive changes to the internals of the bundle encoder.

[sagudev]

For history the first commit was bd7a941

[sagudev]

I think we still need changes to the API because right now all the functions take &mut RenderBundleEncoder which will have to be replaced with id::RenderBundleEncoder (same for render/compute passes). At least for Firefox we can't move onto the new API unless we move all encoder recording out of the content process and we can't do that unless the encoder creation methods can create the encoders with an ID + all the encoder methods take IDs. In the meantime we might be able to get away with some sort of 2nd Registry for encoders but that seems like it's more effort than it's worth.

We already have separate registry (HashMap) in servo so I though that was also something firefox could do to bypass the problem, but I know it's not elegant. IIRC when passes were refactored I asked about them going out of global. It's somehow ironically how we need to move them back in just so we will be able to get them out again in the future. So I guess I need to do this too.