Pending wait-before-signal with WSI presentation is broken on Windows

This sample uncovered a kernel-level issue on the Windows platform https://github.com/KhronosGroup/Vulkan-Samples/pull/238.

The sample demonstrates wait-before-signal extensively and I can trigger a full hang where the process becomes un-killable, and the computer cannot restart safely without cutting power. Applications should never be able to compromise system stability like this. The issue also happens on both AMD and NV. The sample also works just fine on Linux and Android drivers.

The sample ensures to satisfy the spec wording for binary semaphores which is:
> VUID-vkQueuePresentKHR-pWaitSemaphores-03268
All elements of the pWaitSemaphores member of pPresentInfo must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations **on which it depends (if any) must have also been submitted for execution**

This is the only real requirement for submission order in the spec, there is no wording otherwise.

However, the async submission thread runs ahead and submits work which depends on the graphics/presentation queue in future frames.

The issue happens when calling vkQueuePresentKHR, where the system becomes unstable. My theory is that presenting on Windows requires waiting for **all** queues to complete in finite time before the present can fire. The problem here is that the async queue is blocked and cannot make forward progress until the graphics queue renders, so any attempt to fully drain the device will deadlock.

Start by reviewing the referenced Vulkan-Samples pull request and the vkQueuePresentKHR behavior described under VUID-vkQueuePresentKHR-pWaitSemaphores-03268. The report names no Vulkan-Docs file, test, or documentation change; done would require an agreed repository scope and a reproducible resolution.

Written by the indexing model from the issue text.