`spirv-std` features for APIs that are not universally available

OTOH, there does exist a SequentiallyConsistent in SPIR-V, so if we wanted to, we could move the error to the new SPIR-T-based validator pass, so you're only going to see if the match ordering {...} doesn't get optimized away.

Originally posted by @eddyb in #399

This is another frustrating part of rust-gpu for me. It exposes all possible permutations of things possible in SPIR-V, even though some of them are only possible in a specific version, some only in OpenCL (is it even a relevant target at this point?), and some are technically valid for Vulkan as such, but not supported by WebGPU/wgpu.

It'd be nice if spirv-std had features flags that hide certain APIs that are specific to Vulkan-only or OpenCL-only or require a specific SPIR-V version (ideally, with Vulkan version aliases).

Some meta feature that only exposes portable features usable with wgpu would be useful as well, but that might be a stretch (though it would be a serious usability improvement).

Beginne mit der Überprüfung der API-Oberfläche von spirv-std und der referenzierten Diskussion zu den SPIR-V- und SPIR-T-Validatoren. Lege fest, welche APIs durch Vulkan-, OpenCL-, SPIR-V- oder wgpu-Portabilitätsanforderungen eingeschränkt werden sollten, und prüfe, wie Feature-Aliase dargestellt würden; als abgeschlossen gilt die Aufgabe, wenn die Feature-Grenzen und das Portabilitätsverhalten spezifiziert und implementiert sind.