SpvBuilder::makeArrayType doesn't set the stride decoration

SpvBuilder::makeArrayType takes the stride as an argument, and checks if it's not zero to see whether to try to reuse an existing instance or to unconditionally create a new one. However, it only uses the stride for this purpose — it doesn't apply the actual DecorationArrayStride to the newly created type, making you have to set it externally after creating the type.

In GlslangToSpv, there are two places where the stride is currently being applied after a makeArrayType call — in one place, immediately if it's not zero, and in another, after choosing whether to make a sized array or a runtime one (a new instance of a runtime array is created unconditionally, by the way, wondering if deduplication can theoretically apply to them too).

Is this by design, or just an oversight (along with the lack of deduplication of arrays with strides — is there something preventing the builder for searching for a previously created array not just by the type and size, but by the stride as well)? If this is fixed, however, it will slightly break compatibility with other projects using the builder — the decoration will be added twice (maybe some deduplication for decorations would be nice as well though).

Start with SpvBuilder::makeArrayType and the two GlslangToSpv call sites described in the issue, then inspect how DecorationArrayStride is applied and how array types are reused. Determine the intended behavior for sized and runtime arrays, including compatibility with existing callers; done means the behavior is covered consistently without unintended duplicate decorations.

Written by the indexing model from the issue text.