Implement `texture_formats_tier1` language extension

[andyleiserson]

This was recently added in gpuweb/gpuweb#5526.

Naga should accept the relevant texture_storage types if and only if the language extension is available.

This actually may be relatively trivial, in that we already parse the types and can just report support for the extension. However, it seems like there is potential for confusion if we report support for the texture_formats_tier1 language extension while not actually supporting the texture-formats-tier1 adapter feature (#8122).

[ErichDonGubler]

I guess I'm confused; why is this not a duplicate of #8122?

[andyleiserson]

I was confused too, maybe I still am...

This one is for the WGSL language feature (what things you can say in a well-formed WGSL program). #8122 is for the adapter feature (the kinds of rendering operations that are supported).

Which doesn't necessarily mean they're not duplicates, the two things are obviously closely related. The background for this (besides the link in the description to gpuweb/gpuweb#5526) is gpuweb/gpuweb#5524 and gpuweb/cts#4567, which came from my effort to make the CTS test webgpu:shader,validation,extension,readonly_and_readwrite_storage_textures:* pass.

I thought it might be possible to make the CTS test pass, without fully addressing #8122. But after studying the situation, I realized that naga is currently accepting the tier1 texture formats without reporting the language extension (somewhat excepting the 16-bit norm formats, since wgpu has a dedicated feature for those). So the ways to make a corrected version of the CTS test pass are either:

1. Stop accepting those storage texture formats in naga. This seems like it risks breaking things with no real benefit in exchange.
2. Do as it says in the description and report support for the texture_formats_tier1 WGSL language extension without supporting the adapter feature (keeping naga's parsing behavior as-is), but that seems like it creates a potential for confusion with, again, no real benefit in exchange.

Probably I could have just posted this as a comment on #8122, but that didn't align with my mental scoping of the issue.