Use StructureChainBuilder to create the debug callbacks.

[asuessenbach]

Description

Next step in cleaning up the setup process: use the StructureChainBuilder to create the debug callback handles.

Note: For some (to me) unknown reason, in the extensions sample shader_debugprintf, you need the VkDebugUtilsMessengerCreateInfoEXT from that sample as the anchor, not the one from vulkan_sample. That's why you need to do some more work there. The previous implementation happened to make it as needed, but it was actually wrong in the general case.

Build tested on Win11 with VS2022. Run tested on Win11 with NVidia GPU.

General Checklist:

Please ensure the following points are checked:

• My code follows the coding style
• I have reviewed file licenses
• I have commented any added functions (in line with Doxygen)
• I have commented any code that could be hard to understand
• My changes do not add any new compiler warnings
• My changes do not add any new validation layer errors or warnings
• I have used existing framework/helper functions where possible
• My changes do not add any regressions
• I have tested every sample to ensure everything runs correctly
• This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

• I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
• My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

If this PR contains framework changes:

• I did a full batch run using the batch command line argument to make sure all samples still work properly

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

• I have tested the sample on at least one compliant Vulkan implementation
• If the sample is vendor-specific, I have tagged it appropriately
• I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
• Any dependent assets have been merged and published in downstream modules
• For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
• For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
• For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

[SaschaWillems]

Not sure if it's a good idea to hide these behind those defines. What about samples like debugprintf that are supposed to work without validation layers (to be used with e.g. RenderDoc)?

[asuessenbach]

Those two functions hidden by those defines are private helper functions of the VulkanSample class. They are not virtual, and nobody out of this class actually need to know about them.

In contrast to that, extend_instance_create_info and extend_debug_utils_messenger_create_info are protected virtual functions in VulkanSample, not hidden by any defines. The shader_debugprintf sample, for example, overrides them and calls it own local helper function get_debug_utils_messenger_create_info, which is not hidden behind any defines.

[SaschaWillems]

Not a fan of this. Samples like this are supposed to explicitly show how to set up things. Moving them to the framework and making things implicit makes it harder to follow and/or adopt such samples.

[asuessenbach]

Not a fan of this.

What exactly don't you like here?
The usage of the StructureChainBuilder to ease structure chaining? Or the use of a local helper function to get the very same VkDebugUtilsMessengerCreateInfoEXT in two separate functions?