gfxrecon-convert --include-binaries does not work correctly for VkShaderCreateInfoEXT or VkShaderModuleCreateInfo in VkPipelineShaderStageCreateInfo

[w-pearson]

Describe the bug:
The --include-binaries option on gfxrecon-convert doesn't work properly for two uncommon ways of creating shaders. For VkShaderCreateInfoEXT/vkCreateShadersEXT (VK_EXT_shader_object), the value of pCode is always put into the generated JSON file (even if --include-binaries is not specified). For VkShaderModuleCreateInfo specified in the pNext chain of VkPipelineShaderStageCreateInfo, the text [Binary data] is always used for pCode (even if --include-binaries is specified).

Build Environment:
Built from 8f763b8.

To Reproduce:
For the VkShaderModuleCreateInfo in VkPipelineShaderStageCreateInfo issue, the graphics_pipeline_library demo from KhronosGroup/Vulkan-Samples@16cd61e can be used. (The graphics pipeline library extension apparently introduced this functionality, though it uses the same spirv for all of its pipelines.)

For the VkShaderCreateInfoEXT issue, the shader_object demo can be used. Note that capturing this is more annoying, as the VK_LAYER_KHRONOS_shader_object layer needs to be after the GFXR layer (which doesn't happen with gfxrecon-capture-vulkan.py). set VK_LAYER_PATH=C:\Users\w.pearson\source\repos\gfxreconstruct\build\windows\x64\output\bin;C:\VulkanSDK\1.3.280.0\Bin and set VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_shader_object;VK_LAYER_LUNARG_gfxreconstruct works for this.

Capture a GFXR file, and then use gfxrecon-convert to get a JSON version. Then search for VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO (ignoring the 2 initial calls to vkCreateShaderModule) or VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT.

System environment:

• NVIDIA GeForce RTX 4070 Laptop GPU, driver version 537.34.0.0. Windows 10.

Notes:
Related to #1367.

This happens because the custom handling for VkShaderModuleCreateInfo always writes [Binary data] (the comment saying it will be replaced is wrong):

gfxreconstruct/framework/decode/custom_vulkan_struct_to_json.cpp

Lines 307 to 323 in 8f763b8

	void FieldToJson(nlohmann::ordered_json& jdata,
	const Decoded_VkShaderModuleCreateInfo* data,
	const JsonOptions& options)
	{
	if (data && data->decoded_value)
	{
	const auto& decoded_value = *data->decoded_value;
	const auto& meta_struct = *data;
	FieldToJson(jdata["sType"], decoded_value.sType, options);
	FieldToJson(VkShaderModuleCreateFlags_t(), jdata["flags"], decoded_value.flags, options);
	FieldToJson(jdata["codeSize"], decoded_value.codeSize, options);
	// Use "[Binary data]" as placeholder. It will be replaced with a file path if the JSON
	// consumer decides to dump binaries in separate files.
	FieldToJson(jdata["pCode"], "[Binary data]", options);
	FieldToJson(jdata["pNext"], meta_struct.pNext, options);
	}
	}

VulkanExportJsonConsumerBase::Process_vkCreateShaderModule uses RepresentBinaryFile (from json_writer.cpp, not json_util.cpp) for the VkShaderModuleCreateInfo, so vkCreateShaderModule is not affected. But there is no special handling for vkCreateGraphicsPipelines and its pNext chain, so the implementation in custom_vulkan_struct_to_json.cpp gets used. There also isn't any special handling for vkCreateShadersEXT or VkShaderCreateInfoEXT, so an auto-generated implementation is used (which just treats pCode as raw data).

Note that there's also a broken special implementation for VkPipelineCacheCreateInfo, but this goes unused because VulkanExportJsonConsumerBase::Process_vkCreatePipelineCache handles it correctly. I think this doesn't cause any problems in practice (as VkPipelineCacheCreateInfo doesn't appear anywhere else, in particular not in a pNext chain).