Use Vulkan API 1.0 support funcs for Vulkan API 1.0 sample host_image_copy

[SRSaunders]

Description

This PR replaces Vulkan 1.1 API support function vkGetPhysicalDeviceFormatProperties2() with Vulkan 1.0 equivalent vkGetPhysicalDeviceFormatProperties2KHR() for Vulkan API 1.0 sample _host_imagecopy. This prevents runtime failures (undefined functions) on Vulkan drivers that enforce the specified API version.

I did not up-version the sample to Vulkan API 1.1 since it appears that Vulkan API 1.0 was the intended API version, with extensions enabled by VK_KHR_get_physical_device_properties2.

Tested on macOS Ventura and iOS 17 using both the Vulkan loader and MoltenVK standalone.

General Checklist:

Please ensure the following points are checked:

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

• [x] This PR describes the scope and expected impact of the changes I am making

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

  • [x] I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
  • [x] 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:

• [x] I have tested the sample on at least one compliant Vulkan implementation
• [ ] If the sample is vendor-specific, I have tagged it appropriately
• [x] 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]

Shouldn't we also use VkFormatProperties2KHR instead of VkFormatProperties2 then?

[SRSaunders]

Shouldn't we also use VkFormatProperties2KHR instead of VkFormatProperties2 then?

That's a natural question, but the Vulkan Spec seems to say otherwise. See https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/vkGetPhysicalDeviceFormatProperties2.html. Both versions of the function (API 1.1 and 1.0) reference VkFormatProperties2, and this seems to be borne out by the header files.

However, for readability and consistency, I could make the change since the following is also true (see https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkFormatProperties2.html):

 // Provided by VK_KHR_get_physical_device_properties2
typedef VkFormatProperties2 VkFormatProperties2KHR;

The current change works as is, but please let me know what you would prefer.

[SaschaWillems]

If we use the KHR suffix in one place, we should use it in the other places too to make it consistent.