examples: Prevent invalid semaphore reuse across frames

[MarijnS95]

Fixes #917
Closes #941
Closes #979

Caution

The example teaches bad practices when it comes to performance. I have a change in flight that switches them to triple-buffering which inevitably replaces the second commit. We may prefer going that route instead.

examples: Have a unique semaphore per swapchain image

This resolves VUID-vkQueueSubmit-pSignalSemaphores-00067 as explained at https://docs.vulkan.org/guide/latest/swapchain_semaphore_reuse.html.

A unique semaphore should be used per swapchain image, because the presentation engine may still reference and use it before the image index it was used with is returned out of acquire_next_image() again.

Alternatives include waiting for the Fence from presentation in VkSwapchainPresentFenceInfoKHR, added by the VK_EXT_swapchain_maintenance1/VK_KHR_swapchain_maintenance1 extension but this is less performant than just using a unique semaphore per swapchain image.

examples: Wait earlier for command-buffer fence to prevent semaphore reuse

This resolves VUID-vkAcquireNextImageKHR-semaphore-01779 where acquire_next_image() is asked to signal a semaphore that may still be waited on by the currently-running submit.

Since the next submit is reusing the existing command buffer and resources as well it must inevitably wait on a fence from the previous frame/submit, pulling out that fence to wait on it is the most practical approach despite teaching bad/slow practices.

Note that this fence was also used to "reuse" the setup command buffer in the texture sample; this was instead generalized to use another command buffer without waiting for and signaling any fence.

examples: Implement triple-buffering

This removes a per-frame stall and demonstrates how users should utilize Vulkan to keep the GPU fed with rendering work, as long as that work (and corresponding presentation requests) complete before we're getting 3 frames ahead.

Note that this does not implement proper frame throttling, and may render lots of discarded frames.

It is an alternative solution to solving VUID-vkAcquireNextImageKHR-semaphore-01779 by also using a unique Semaphore that we know is no longer waited on via previously waiting on the relevant Fence; although similar in nature to the previous solution.

[Ralith]

Triple-buffering sounds nice!