Add VVL tests for VK_KHR_maintenance5 pipeline shader module create info and VK_EXT_shader_module_identifier

[aqnuep]

Environment:

• OS: N/A
• GPU and driver version: N/A
• SDK or header version if building from repo: N/A
• Options enabled (synchronization, best practices, etc.): N/A

Describe the Issue

There are no VVL tests for the following types of shader module usages:

1. Tests when the VK_KHR_maintenance5 feature allowing the application to not use VkShaderModule objects, but instead specify shader module information inline, by including VkShaderModuleCreateInfo in the pNext chain of VkPipelineShaderStageCreateInfo
2. Tests when the VK_EXT_shader_module_identifier extension is used

Expected behavior

Validation for these features should work as expected and should continue to work as expected, which requires appropriate VVL test coverage.

Valid Usage ID

All shader module related VUIDs.

Additional context

About 5 months ago there was a refactoring of SPIR-V validation separating "stateless" (i.e. only device state dependent) validation from pipeline state dependent validation, and these checks were moved from being detected during vkCreate*Pipelines to vkCreateShaderModule, vkCreateShadersEXT, etc.

Until recently, this was broken (there was no SPIR-V validation at all) when including VkShaderModuleCreateInfo in the pNext chain of VkPipelineShaderStageCreateInfo due to the lack of test coverage. In order to make sure this won't break again, we need new VVL tests to cover this case.

Similarly, before that another refactoring round broke VK_EXT_shader_module_identifier validation, where a shader module and SPIR-V module data itself is optional as a whole, causing crashes in the validation layer because of the invalid expectation of SPIR-V module data to be always available. In order to make sure this won't break again, we need new VVL tests to cover this case.

[spencer-lunarg]

There are no VVL tests for the following types of shader module usages:

For 1 there for sure is because I added them recently in #8162

this whole thing has become a big mess

background - for Pipelines, because of details of GPL, we decided to create the vvl::Pipeline state object first. We also needed to reduce our memory footprint in pipelines/shader object so we made StatelessSpirv checks so we didn't have to hold the memory.... then I tried to add support for inlining in VK_KHR_maintenance5

we need new VVL tests to cover this case.

So I added new tests and confirmed the VK_KHR_maintenance5 worked, will try testing it with combination of VK_EXT_shader_module_identifier