Fix support for VK_KHR_pipeline_binary

[marius-pelegrin-arm]

VkPipelineCreateInfoKHR is a particular structure as it can take any kind of PipelineCreateInfo in its pNext chain, in addition to being required to have a non-null pNext member.

This was not correctly handled by the generated code because Vk*PipelineCreateInfo structures don't have the structextends flag set in the Vulkan registry. This commit aims at fixing that by blacklisting this structure and writing the encoder/decoders manually.

Ideally, this should be solved in the codegen by not considering only structs with the structextends flag as possible encounters in a pNext chain

[ci-tester-lunarg]

CI gfxreconstruct build queued with queue ID 633685.

[ci-tester-lunarg]

CI gfxreconstruct build # 8717 running.

[ci-tester-lunarg]

CI gfxreconstruct build # 8717 passed.

[MarkY-LunarG]

This seems similar to the way OpenXR handles parent/child classes (for example look at XrEventDataBaseHeader and it's derivatives including how Decoded_XrEventDataBaseHeader performs a lot of work for allocations). Additionally, we have hooks in place to handle the proper look-ahead required and handling for static and dynamic arrays. For example, decoding with DecodeBaseHeader instead of the standard decode.

Honestly, this really does seem like something the Vulkan registry is missing as well. In OpenXR, the registry has field tags indicating when a structure has a parent structure (parentstruct="<parent-struct-name>"). For example, in this case, all the other "CreateInfos" would be listed with parentstruct="VkPipelineCreateInfoKHR".
But we can focus on that later and do "custom" functionality for now here.

[MarkY-LunarG]

I made a change in PR #2668, try that out.