Update spirv-tools

[Jake-Shadle]

• Update spirv-tools
• Update spirv-tools installs to latest-ish

Updates spirv-tools to 2022.4 (and 2022.3 and 2022.2 because I have been slacking).

---

EDIT(@eddyb): marked as draft after rebasing onto (and blocking on):

• attr: fix #[spirv(flat)] checking to match the Vulkan spec. #933

[eddyb]

Now that the whole deal in #928 (comment) has been fixed, I've bumped the spirv-tools version further so we should get better errors on CI now.

---

Also moving #928 (comment) here to be able to hide it:

Hah, you bumped all of these by 116 CI builds, so they are in lock-step, just with an offset from their initial setup at the very start? We could use that to our advantage and write a script that finds a set of 3 for a specific date - once we have e.g. the macOS CI build ID, we can derive the others from it and query the bucket for e.g. ".../${macos_id - 12}/${date}-*/install.tgz".

It's a bit messy but as long as we can do 3-4 curl requests in CI we can avoid hardcoding anything more than that one CI build ID (and even that we might be able to derive from the date if it's a reliably-daily build...).

(i.e. I thought maybe we could automate it - however it is annoying to do this on 3 different platforms when I only trust one of them to have the right tools for quickly script this, without e.g. reaching for Python)

[eddyb]

I talked to @Jake-Shadle and there's some good ideas around moving away from this model to something that both avoids so many builds of the C++ code and avoids dealing with potentially-wildly-different system-installed tooling. (At the very least the system-installed mode could move to linking against the .a libraries, which could then be switched from "weird GCP CI artifacts bucket" to our own builds)

For now I want to merge this for the test fixes (when using system-installed SPIRV-Tools on other branches).