Awkward synchronization requirements imposed on Vulkan-capable implementations

`xrAcquireSwapchainImage` is the only function which the application must call before submitting commands that access a swapchain image which is also permitted by `XR_KHR_vulkan_enable` to access the application's graphics queue. Sharing swapchain images with a compositor requires that the OpenXR implementation submit acquire/release barriers enclosing the application's work on the application's queue, corresponding to release/acquire barriers on the compositor's queue. Hence, `xrAcquireSwapchainImage` must submit an acquire barrier to a Vulkan application's queue.

Such a barrier must have an execution dependency on the compositor's corresponding "release" barrier. Because a traditional Vulkan semaphore cannot be waited on until a submission has been made that will signal it, implementing such a dependency with one requires blocking the CPU in `xrAcquireSwapchainImage` on the compositor's submission of its corresponding release barrier, which seems to defeat the purpose of a separate `xrWaitSwapchainImage` call.

This can be worked around with timeline semaphores, but that prevents compatibility with older drivers, and presumably wasn't the intention of the spec as it leaves `xrWaitSwapchainImage` as a noop. Alternatively, semaphores could perhaps be replaced with `VkEvent`s that are signaled after blocking the CPU in `xrWaitSwapchainImage`, but this is unconventional, and events are thought to be poorly supported by most Vulkan implementations.

Read the synchronization requirements described for xrAcquireSwapchainImage, xrWaitSwapchainImage, and XR_KHR_vulkan_enable, focusing on the semaphore and VkEvent alternatives raised here. The issue is done when the intended synchronization behavior and compatibility requirements are clarified in the OpenXR specification.

Written by the indexing model from the issue text.