[naga] Support pipeline overrides in the WGSL backend

[cbbowen]

Connections
#4484

Description
The WGSL backend currently does not support pipeline overrides (i.e. override foo: f32). These are included in the latest WGSL spec, this PR adds support for them by:

1. Generating appropriate override declarations in wgsl::Writer.
2. Handling Override expressions in wgsl::Writer.
3. Handling Unary and Binary constant expressions in wgsl::Writer.

This last step was necessary because the existing "overrides" snapshot test exercises the functionality, but it isn't currently implemented for the WGSL backend.

Testing
The first commit in this PR enables the existing "overrides" snapshot tests for the WGSL target which I verified fails. The following commits update the backend such that it passes and generates semantically equivalent WGSL to the input.

Ran:

cargo test --all-features
cargo xtask validate wgsl

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[cwfitzgerald]

Just to help the naga reviewers: the testing looks good on this PR

[ErichDonGubler]

I feel confident that the behavior intended to be allowed here is correct, but I don't feel confident that we're rejecting improper programs. I'm not very familiar with overrides to begin with. @jimblandy, could we maybe pair on this, so I can get your thoughts?

[ErichDonGubler]

@jimblandy: I intend to merge this in the next 24 hours, unless you have an objection.

[jimblandy]

Rather than adding limited support for some operations to back::wgsl::writer, you should just make write_output_wgsl in naga/tests/snapshots.rs call naga::back::pipeline_constants::process_overrides, the way the other write_output_foo functions do.

[jimblandy]

Going a bit further than my previous comment:

I don't think this PR is the right approach. Naga backends should assume that overrides' values have been provided, and the module has been rewritten so that all overrides appear as constants instead. So rather than the approach taken here, I think the WGSL backend should handle overrides the same way the other backends do:

        if !module.overrides.is_empty() {
            return Err(Error::Override);
        }

As explained in the prior review, it should be the caller's responsibility to call pipeline_constants::process_overrides and eliminate all overrides from the module before passing it to the backend.

[cbbowen]

To verify I understand, the intent is that modules with pipeline overrides should not be translated from one language to another? They must instead be substituted with concrete values. That precludes some use cases, including mine, but I can understand not wanting to take on that maintenance burden. If that understanding is correct, I can close this PR.