[naga] Always compact the module in process_overrides

[andyleiserson]

This should fix #7638, but I don't have a Windows system, so I can't 100% confirm that.

This change mostly avoids the issues in #7793 by only compacting (not attempting override resolution) if the module doesn't have any overrides. I've also optimized the case where there is only one entry point, although I'm not sure that's a good idea -- it may be possible to write a module with one entry point and a problematic global that is not used by the entry point, and we'd need to compact that module to get rid of the problematic global.

Testing
I'm open to suggestions what tests make sense here. I considered writing a test in naga::validation that verifies compaction has taken place, but it doesn't feel like it adds a lot of value. Possibly there are some tests that can be added with #7734, although it will be difficult to distinguish the effects of this change vs. #7626. We could also create a test based on the test case in #7638, but I don't have a windows machine to work on that.

Squash or Rebase? Squash

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[jimblandy]

For testing, I'm fuzzy on the details, but couldn't we adopt the test case from #7793 for this?