Duplicate binding validation in Vulkan environments

This is more of a question than a bug report, but I was surprised by spirv-val not complaining about duplicate set/binding declarations in Vulkan environments. For example, the following GLSL:

```
#version 450
layout(set=0, binding=0) uniform Foo {
vec4 foo;
};
layout(set=0, binding=0) uniform sampler2D bar;
void main()
{
vec4 test = foo + texture(bar, vec2(0, 0));
}
```

With duplicate entries for set/binding 0/0, incompatible types and where both are statically used by main, is translated to the following SPIR-V by glslang:

```
; SPIR-V
; Version: 1.0
; Generator: Khronos Glslang Reference Front End; 10
; Bound: 28
; Schema: 0
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint GLCompute %main "main"
OpExecutionMode %main LocalSize 1 1 1
OpSource GLSL 450
OpName %main "main"
OpName %test "test"
OpName %Foo "Foo"
OpMemberName %Foo 0 "foo"
OpName %_ ""
OpName %bar "bar"
OpMemberDecorate %Foo 0 Offset 0
OpDecorate %Foo Block
OpDecorate %_ DescriptorSet 0
OpDecorate %_ Binding 0
OpDecorate %bar DescriptorSet 0
OpDecorate %bar Binding 0
%void = OpTypeVoid
%3 = OpTypeFunction %void
%float = OpTypeFloat 32
%v4float = OpTypeVector %float 4
%_ptr_Function_v4float = OpTypePointer Function %v4float
%Foo = OpTypeStruct %v4float
%_ptr_Uniform_Foo = OpTypePointer Uniform %Foo
%_ = OpVariable %_ptr_Uniform_Foo Uniform
%int = OpTypeInt 32 1
%int_0 = OpConstant %int 0
%_ptr_Uniform_v4float = OpTypePointer Uniform %v4float
%18 = OpTypeImage %float 2D 0 0 0 1 Unknown
%19 = OpTypeSampledImage %18
%_ptr_UniformConstant_19 = OpTypePointer UniformConstant %19
%bar = OpVariable %_ptr_UniformConstant_19 UniformConstant
%v2float = OpTypeVector %float 2
%float_0 = OpConstant %float 0
%25 = OpConstantComposite %v2float %float_0 %float_0
%main = OpFunction %void None %3
%5 = OpLabel
%test = OpVariable %_ptr_Function_v4float Function
%16 = OpAccessChain %_ptr_Uniform_v4float %_ %int_0
%17 = OpLoad %v4float %16
%22 = OpLoad %19 %bar
%26 = OpImageSampleExplicitLod %v4float %22 %25 Lod %float_0
%27 = OpFAdd %v4float %17 %26
OpStore %test %27
OpReturn
OpFunctionEnd
```

But spirv-val considers that valid with a Vulkan environment:

```
$ spirv-val --target-env vulkan1.0 test.spv
$ echo $?
0
```

I've seen the SPIR-V spec redirects you to the client API spec for DescriptorSet and Binding and there's a [section of the Vulkan spec related to that](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#interfaces-resources-setandbinding) that mentions the following in a note:

> If multiple shader variables with the same set and binding values are declared in a single shader, but with different declared types, where any of those are not supported by the relevant bound descriptor, that shader can only be executed if the variables with the unsupported type are not statically used.

I'm wondering if that should make spirv-val complain about cases like the one above. Thanks in advance.

Start by reproducing the example with spirv-val --target-env vulkan1.0 and read the Vulkan set-and-binding section linked in the issue. Determine whether statically used duplicate bindings with incompatible types should be rejected, then verify the expected validator behavior against this SPIR-V example.

Written by the indexing model from the issue text.