Ray tracing pipelines for wgpu

[Vecvec]

Connections
Depends on #9085
Part of #6760

Description
Adds the various ray tracing pipelines and ray tracing passes to wgpu. Work in progress - the main API is finished, but there are a few outstanding questions:

1. How to expose sbt hit data on metal in ray queries (and should this even be done)?
   • Vulkan & DX12 expose shader binding table data to ray queries (its just extra data that uses the same field). Metal does not expose this, so the metal backend in naga zeros this field. This was fine - this field was always zero, but this PR allows users to have data in here which breaks on metal. I'm hoping there is some way to change this
2. Should shader binding tables (SBTs) be part of the ray tracing pipeline?
   • (This could probably wait until another PR) To keep the similarities between the other pipelines and to lower the complexity of the implementation (possibly, I haven't tried to implement it with these seperate), and because I haven't seen a use-case for multiple sbts for the same pipeline, the shader binding tables are part of the ray tracing pipeline. If there are use-cases for these being separate, it might be worth making them seperate in wgpu too.

CC @JMS55 who may have opinions on these questions

Testing
A test for in and out of bound pipeline indices

Squash or Rebase?

If your pull request contains multiple commits, please indicate whether
they need to be squashed into a single commit before they're merged,
or if they're ready to rebase onto trunk as they stand. In the
latter case, please ensure that each commit passes all CI tests, so
that we can continue to bisect along trunk to isolate bugs.

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.

[JMS55]

Love to see this!

Tbh I don't really know much about SBT - I haven't read up about them at all.

I'm mostly looking forward to RT pipelines for access to SER, not for support for multiple materials (SBT).

Will trust you to decide what to do for SBT.

Might also be worthwhile looking at what Godot did: godotengine/godot#118044

[inner-daemons]

Holy shit, thanks so much. This is amazing.

[Vecvec]

Tbh I don't really know much about SBT - I haven't read up about them at all.

I'm mostly looking forward to RT pipelines for access to SER, not for support for multiple materials (SBT).

Will trust you to decide what to do for SBT.

In that case, I will proceed with the current design. Although adding sbts would be breaking change, for the user I think it would only be a few lines for the normal use-case (one to create the default sbt and one per trace ray call).