Still not possible to safely destroy semaphore used with present (without mandatory extension use)

As per #152, without use of extensions it is still not possible to safely destroy (or reuse) wait semaphores used with vkQueuePresentKHR, because there is no way to "retire" the semaphores and even things like vk*WaitIdle are specified as not covering the case.

This results in a situation where applications and implementations are forced to hallucinate unsupported ad-hoc "solutions" with the hope their code is correct™ (i.e. hoping it will always work and keep working).

The problematic parts to cover are:

• What to do if a new application encounters an old driver that does not support the extensions that "fix" it. Current state is to copy-paste code from some trusted source (tutorial, your favorite expert\influencer, an insider you know, etc), and hope it is reliable.
• What to do if a new driver encounters and old application not aware of the extensions that "fix" it. With the existence of the new extensions, new drivers might be tempted to do things slightly differently internally now (in the light the spec leaves it undefined land), which might break previous apps that made their best effort (per previous bullet point) to deal with the spec defect.
• Technically it is also a concern of Validation Layers, which need to make careveouts for some undefined behavior uses at their own discretion permitting for the common "workarounds" people do, while normally layers should be as strict as possible.

ANGLE materials mention one such set of "workarounds":

• In the case of swapchain recreation, it hopes the semaphores are retired in present order, so when new swapchain is made, it keeps delayedly destroying old semaphores as it presents something and acquires it back. Some apps do perhaps hope present is covered by simply submission order.
• There doen't seem to be a mention what to do when no new swapchain is to be created. But I believe most apps would use vk*WaitIdle and hope that gets it done, but some might equally rely on hope that plain submission order takes care of the present semaphores.

So those are all cases any new drivers might need to honor (even if specification does not say so).

Additionally, the new extensions seem to strongly imply it was not safe to destroy the Swapchain itself:

and can destroy the swapchain when the fences associated with all past presentation requests have signaled.

But vkDestroySwapchainKHR specification seems to say it is fine dealing with outstanding images:

All uses of presentable images acquired from swapchain must have completed execution

The memory of each VkImage will only be freed after that image is no longer used by the presentation engine. For example, if one image of the swapchain is being displayed in a window, the memory for that image may not be freed until the window is destroyed, or another swapchain is created for the window.

Read the issue context, related issue #152, and the linked ANGLE PresentSemaphores.md material. Compare the vkQueuePresentKHR semaphore concerns with the vkDestroySwapchainKHR wording and extension behavior described here. Done means reaching and documenting a clear specification decision that addresses old and new applications, drivers, and validation layers.