[naga] resolve the size of override-sized arrays in backends

[teoxoy]

Connections
Fixes #6722
Closes #6746

Description
Implements Jim's suggestion of resolving the size of override-sized arrays in backends so that we don't have to rebuild the types arena when processing overrides.

Testing
The new and existing tests passed.

[kentslaney]

I'm confused about the status of this PR. In #6746 you said

I think it turned out well

but in #6788 you say

ultimately my attempt didn't work

Am I misreading or did something change? And where does this leave #6746?

[teoxoy]

but in #6788 you say

ultimately my attempt didn't work

In #6788 (comment) I was specifically talking about the issue Jim brought up in #6788; this PR doesn't touch the compactor.

And where does this leave #6746?

This PR obsoletes #6746.

[jimblandy]

Still reviewing.

[jimblandy]

This could almost be a bug fix in its own right.

[kentslaney]

@cwfitzgerald via Wgpu Users in reply to @junglie85

I assume I can parse a wgsl shaders through naga at build time to generate the module, then load that from disk (or embed bytes) at runtime? Does the module still need to be compiled to a specific backend format when creating the shader module from the naga module?

You can theoretically do it, as you can serialize a Naga module, but yeah we still need to translate it at runtime up hlsl/glsl/spirv/msl

Wouldn't this mean that it's better to resolve the size of override-sized arrays on the front end to minimize runtime overhead?

[cwfitzgerald]

Eh, way more work than the gain - that's not a very common workflow.