add tests for multiple SPIR-V OpSpecConstant instructions with the same SpecId

[bashbaug]

See: https://github.com/KhronosGroup/SPIRV-Registry/issues/357

We should add tests to ensure implementations properly handle cases when multiple OpSpecConstant instructions are decorated with the same SpecId.

Rough test plan:

• Top Priority: Tests for multiple OpSpecConstant instructions:
  • [ ] Test multiple OpSpecConstant instructions with the same default value without specialization.
  • [ ] Test multiple OpSpecConstant instructions with the same default value with specialization.
  • [ ] Test multiple OpSpecConstant instructions with different default values without specialization.
  • [ ] Test multiple OpSpecConstant instructions with different default values with specialization.
• Additional tests for multiple OpSpecConstant instructions:
  • [ ] Test multiple OpSpecConstant instructions with different types (but the same size) and different default values without specialization.
  • [ ] Test multiple OpSpecConstant instructions with different types (but the same size) and different default values with specialization.
  • Probably not? Test multiple OpSpecConstant instructions with different types and different sizes. These cases are unable to be specialized, since clSetProgramSpecializationConstant requires the passed-in spec_size to match the size of the specialization constant in the SPIR-V module.
• Tests for boolean OpSpecConstantTrue / OpSpecConstantFalse instructions:
  • [ ] Test multiple OpSpecConstantTrue instructions without specialization.
  • [ ] Test mixed OpSpecConstantTrue and OpSpecConstantFalse instructions without specialization.
  • [ ] Test mixed OpSpecConstantTrue and OpSpecConstantFalse instructions with specialization.
• Additional tests for mixed instructions:
  • [ ] Test OpSpecConstant and OpSpecConstantNull without specialization.
  • [ ] Test OpSpecConstant and OpSpecConstantNull with specialization.
  • [ ] Test OpSpecConstant and either OpSpecConstantTrue or OpSpecConstantFalse without specialization.
  • [ ] Test OpSpecConstant and either OpSpecConstantTrue or OpSpecConstantFalse with specialization.
  • [ ] Test OpConstantNull and either OpSpecConstantTrue or OpSpecConstantFalse without specialization.
  • [ ] Test OpConstantNull and either OpSpecConstantTrue or OpSpecConstantFalse with specialization.

The tests deemed "top priority" are those that I believe are most likely to occur in the wild and are therefore those that I believe we should implement first. The others cover corner cases and could be implemented at a later date, if desired.