[SPIRV] wrong ArrayStride inside layout(std430) cbuffer

[davli-nv]

Issue Description

ArrayStride is wrong for arrays inside layout(std430) cbuffer compared to ConstantBuffer<T, Std430DataLayout>.
This might be related to #7735, maybe modifiers for cbuffer are being silently ignored in parseHLSLCBufferDecl() depending on parser->options.allowGLSLInput?

Reproducer Code

layout(std430) cbuffer CBlock {
    int2 bb[2];
};
struct B {
    int2 a[2];
};
ConstantBuffer<B, Std430DataLayout> c;
float4 imageMain(uint2 dispatchThreadID, int2 screenSize)
{
    return float4(0.3, 0.7, 0.55, 1.0
    + bb[1].y
    + c.a[0].x
    );
}

Actual Behavior

the ConstantBuffer<> and cbuffer members have different ArrayStride, and notice the _std140

               OpDecorate %_arr_v2int_int_2 ArrayStride 16
               OpMemberDecorate %_Array_std140_vector_int_2_2 0 Offset 0
               OpDecorate %SLANG_ParameterGroup_CBlock_std140 Block
               OpMemberDecorate %SLANG_ParameterGroup_CBlock_std140 0 Offset 0
               OpDecorate %CBlock Binding 1
               OpDecorate %CBlock DescriptorSet 0

               OpDecorate %_arr_v2int_int_2_0 ArrayStride 8
               OpMemberDecorate %_Array_std430_vector_int_2_2 0 Offset 0
               OpDecorate %B_std430 Block
               OpMemberDecorate %B_std430 0 Offset 0
               OpDecorate %c Binding 2
               OpDecorate %c DescriptorSet 0

Expected Behavior

std430 should make these int2 array stride be 8.
Instead of silently ignoring the std430 modifier, I think Slang should error?

[csyonghe]

@davli-nv can you take a look at #8432, looks like a legit fix. Can you help bring it to finish?

[davli-nv]

Yes, I'll drive Copilot in the PR, I think it needs to warn/error when layout (std430) etc are used when compiling for other targets, and accept these layout modifiers when compiling for GLSL/SPIRV without requiring -allow-glsl