Compatibility issue between xrCreateSwapchain and VK_KHR_imageless_framebuffer

Hi, I'm using the Vulkan API extension `VK_KHR_imageless_framebuffer` which requires the **framebuffer** object to be created with the **usage flags** that match the `VkImage` attachment when the `VkRenderpass` is started with `vkCmdBeginRenderPass2` with a `VkRenderPassAttachmentBeginInfo` next struct.

The problem is that `xrCreateSwapchain` can add arbitratry flags that the app won't be able to know and it won't be able to succesfully forward to the framebuffer creation flag.

However the validation layer is able to catch this incompatibility when the `VkImage` is create within the same `VkInstance`. This doesn't happen when the image is created externally like on the Meta Quest, but it does happen on my desktop runtime using the Meta Quest Link.

This is how the swapchain is being created:
```cpp
constexpr XrVulkanSwapchainCreateInfoMETA color_swapchain_info_meta{
.type = XR_TYPE_VULKAN_SWAPCHAIN_CREATE_INFO_META,
.additionalCreateFlags = VK_IMAGE_CREATE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_BIT_EXT
};
const XrSwapchainCreateInfo color_swapchain_info{
.type = XR_TYPE_SWAPCHAIN_CREATE_INFO,
.next = has_swapchain_create_info ? &color_swapchain_info_meta : nullptr,
.usageFlags = XR_SWAPCHAIN_USAGE_COLOR_ATTACHMENT_BIT,
.format = color_format,
.sampleCount = view_configs[0].recommendedSwapchainSampleCount,
.width = m_framebuffer_size.width,
.height = m_framebuffer_size.height,
.faceCount = 1,
.arraySize = static_cast(view_configs.size()),
.mipCount = 1
};
if (const XrResult result = xrCreateSwapchain(m_session, &color_swapchain_info, &color_swapchain);
!XR_SUCCEEDED(result))
{
LOGE("xrCreateSwapchain failed: %s", to_string(result));
return false;
}
```
The XrVulkanSwapchainCreateInfoMETA already adds the ability to forward custom flags, however it doesn't allow those to be retrieved back.
It would have been useful if `XrSwapchainImageVulkanKHR` had the `VkImageUsageFlags` field.
```cpp
typedef struct XrSwapchainImageVulkanKHR {
XrStructureType type;
void* XR_MAY_ALIAS next;
VkImage image;
} XrSwapchainImageVulkanKHR;
```
Here's the validation error:
```
Validation Error: [ VUID-VkRenderPassBeginInfo-framebuffer-04627 ] | MessageID = 0x45125641
vkCmdBeginRenderPass2(): pRenderPassBegin->pNext.pAttachments[2].usage is (VK_IMAGE_USA
GE_TRANSFER_SRC_BIT|VK_IMAGE_USAGE_TRANSFER_DST_BIT|VK_IMAGE_USAGE_SAMPLED_BIT|VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT|VK_IM
AGE_USAGE_INPUT_ATTACHMENT_BIT), but the VkFramebuffer was created with vkFramebufferAttachmentsCreateInfo::pAttachmentI
mageInfos[2].usage = VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT.
The Vulkan spec states: If framebuffer was created with a VkFramebufferCreateInfo::flags value that included VK_FRAMEBUF
FER_CREATE_IMAGELESS_BIT, each element of the pAttachments member of a VkRenderPassAttachmentBeginInfo structure include
d in the pNext chain must be a VkImageView with an inherited usage equal to the usage member of the corresponding elemen
t of VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos used to create framebuffer (https://vulkan.lunarg.com/doc
/view/1.4.321.1/windows/antora/spec/latest/chapters/renderpass.html#VUID-VkRenderPassBeginInfo-framebuffer-04627)
Objects: 4
[0] VkRenderPass 0x690000000069[ce_renderpass]
[1] VkFramebuffer 0x6a000000006a[ce_framebuffer]
[2] VkImageView 0x5f000000005f[swapchain_color_view[1]]
[3] VkImage 0x490000000049[swapchain_color[1]]
```
For reference this happens here: https://github.com/omigamedev/choppy/blob/3e285b2c38c489105bb205ec5cee7299989701f4/modules/app/app.cppm#L291
You should be able to reproduce the issue by building and running the project.

Hope this helps improve the API.
Thanks, bye.

Start by reproducing the validation error with the referenced choppy project, especially modules/app/app.cppm around line 291. Read the XrVulkanSwapchainCreateInfoMETA and XrSwapchainImageVulkanKHR definitions alongside xrCreateSwapchain, then determine how swapchain image usage could be exposed for VK_KHR_imageless_framebuffer compatibility. Done means an agreed API and corresponding OpenXR specification update that addresses the reported usage mismatch.

Written by the indexing model from the issue text.