Vulkan: vkQueuePresentKHR call can wait on a semaphore that is not yet signaled

The following Vulkan calls will cause a semaphore waited on by `vkQueuePresentKHR` to be unsignaled at the time of the `vkQueuePresentKHR` call:
```
...
vkCmdWaitEvents(cmdBuffer, 1, &event, ...)
...
submitInfo.pCommandBuffers = &cmdBuffer;
submitInfo.pSignalSemaphores = &semaphore;
vkQueueSubmit(&submitInfo)
...
presentInfo.pWaitSemaphores = &semaphore;
vkQueuePresentKHR(queue, &presentInfo);
...
vkSetEvent(device, event);
```

This is a rare corner case that is unlikely to come up in practice, but the current API model ignores the possibility, causing at least two possible incorrect behaviors:

1. The swapchain image associated with the frame may be shown incorrectly; the correct contents may not be available until the `vkSetEvent` call.
2. The semaphore will be incorrectly left as signaled after `vkSetEvent`; it should be immediately unsignaled by the blocked `vkQueuePresentKHR` call.