Implement VK_EXT_swapchain/surface_maintenance1

Implements the extension in a fairly basic way. There are two core features that everyone must support. Implemented X11, Wayland, KHR_display (trivial), Win32 (blind, just stubbed).

• Present fence. When the fence is signaled, the semaphore and swapchain can be destroyed. This is trivially implemented through a vkQueueSubmit where we do presentID timeline semaphore signal. This is implemented in common code.
• vkReleaseSwapchainImagesEXT. Just un-acquires the image. Trivially implementable. Need to call release_memory_ownership as we'd normally do on a vkQueuePresentKHR.
• Deferred swapchain image allocation. Not really relevant for us, ignore it. As far as I know allocating swapchain memory isn't a big problem for us.

Optional features:

• Scaling control. Unimplemented. Not sure if it's meaningful for us.
• Gravity. Top-left/Center/Bottom-right alignment for swapchains that aren't 1:1. Not sure if it's relevant for us.
• Toggling of presentation modes on the fly. I implemented this for Wayland since we can trivially toggle between MAILBOX and FIFO this way. On X11, we could do this too, but the existing implementation has acquire/present queue threads that complicate things. We'd need to rewrite it to always use threads regardless of present mode. Then we could just push the present mode into wsi_acquire_queue instead, but that has to be revisited later.
• Per-present mode query of minImageCount. For Wayland, return minImageCount = 2 for FIFO only, since that's technically what is required for forward progress. When PresentModeGroupCreateInfo is passed to vkCreateSwapchainKHR, the rules for forward progress are modified to be based on the max of the group's minImageCount rather than the global SurfaceCapabilityKHR::minImageCount. Gives applications that really want 2 or 3 images to do so. It cannot break existing applications that don't explicitly opt-in to this EXT.