Minimally integrate SPIR-T (opt-in via RUSTGPU_CODEGEN_ARGS=--spirt).

[eddyb]

Please see the SPIR-T repository for more information, but to quote the top of its README:

SPIR-🇹

⋯🢒 🇹arget 🠆 🇹ransform 🠆 🇹ranslate ⋯🢒

SPIR-🇹 is a research project aimed at exploring shader-oriented IR designs derived from SPIR-V, and producing a framework around such an IR to facilitate advanced compilation pipelines, beyond what existing SPIR-V tooling allows for.

---

This PR integrates it into Rust-GPU in a very limited capacity, in the middle of a sequence of passes operating on SPIR-V, as a ... -> SPIR-V -> SPIR-T -> SPIR-V -> ... conversion, with the only SPIR-T -> SPIR-T pass being the CFG structurizer (substituting our own structurizer, which we may want to delete?).

That alone is enough to show some compile-time speedups of over 30% in some workloads, while adding only marginal overhead (~0.1%), and it's still being limited by our existing passes (see EmbarkStudios/spirt#6).

---

To enable, you can use RUSTGPU_CODEGEN_ARGS=--spirt - to quote the (more detailed) codegen-args.md docs:

--spirt

Enables using the experimental SPIR-🇹 shader IR framework in the linker - more specifically, this:

• adds a SPIR-V -> SPIR-🇹 -> SPIR-V roundtrip
  (future SPIR-🇹 passes would go in the middle of this, and eventually codegen might not produce SPIR-V at all)
• replaces the existing structurizer with SPIR-🇹 structurization (which is more robust and can e.g. handle OpPhis)
• runs some existing SPIR-V legalization/optimization passes (mem2reg) before inlining, instead of only after (as the OpPhis they would produce are no longer an issue for structurization)

For more information, also see the SPIR-🇹 repository.

--dump-spirt-passes FILE

Dump the SPIR-🇹 module across passes (i.e. all of the versions before/after each pass), as a combined report, to FILE and FILE.html.
_{(the .html version of the report is the recommended form for viewing, as it uses tabling for versions, syntax-highlighting-like styling, and use->def linking)}

---

Opening this PR as a draft because there are some discussions that need to be had, i.e.:

(click to open outdated bullet points)

• how acceptable is the lossiness we get from the SPIR-T structurizer? (see test changes)
  • the debuginfo we don't guarantee so it's maybe fine? we can also improve it over time
  • #[spirv(unroll_loops)] is effectively broken and would need to be rewritten to operate on SPIR-T
    • see also: We should override thir_body to inject loop merge points for structurization. #944
  • EDIT: @fu5ha's comment has a justification for both of these
• should we just delete code this supersedes? (our old structurizer)
• EDIT: the updated plan means only deleting that code when we flip SPIR-T on by default
• should we wait for 0.4 to release, so that the SPIR-T dependency can be only 0.5 onward?
  • this would allow more time to refine it before we need to release spirt 0.1 on crates.io
  • EDIT: the updated plan has SPIR-T as opt-in for 0.4, and by default only later (0.5 or so)

[fu5ha]

• #[spirv(unroll_loops)] is not particularly important -- we don't use it anywhere to my knowledge and gpu shader compilers should be able to do this on their own
• the debug info is also not currently used for anything, I'm unaware of any tools that integrate well with it -- we either cross compile parts of gpu code to cpu or use shader disassemblers built into gpu debugging tools.

[eddyb]

Ooops, had to draft again because I forgot to update the CHANGELOG.