Avoid reusing semaphores that may still be in flight

[AnyOldName3]

Fixes validation error VUID-vkQueueSubmit-pSignalSemaphores-00067

At the moment, this is a little bit too enthusiastic when multiple windows are affected by the same RecordAndSubmitTask. It would be sufficient to use any one of their renderFinishedSemaphores, but one's used from every window. This shouldn't make a major difference to anything, as they'll all be signalled at the same time and waited on by the same presentation, but in principle, redundant semaphores might have some overhead.

If this change isn't satisfactory and some things warrant rearranging, then that might become moot anyway, so I've not done anything about it yet and will wait for feedback before doing so.

[robertosfield]

To help with testing I have merged as a branch:

https://github.com/vsg-dev/VulkanSceneGraph/tree/AnyOldName3-fix-semaphore-reuse

[robertosfield]

I have got back to reviewing this submissions/branch merging the latest VSG master into the https://github.com/vsg-dev/VulkanSceneGraph/tree/AnyOldName3-fix-semaphore-reuse branch.

However, after building under Windows 11 and running on Geforce 2060/Nvidia driver when I run vsgdraw.exe -d I see the following Vulkan validation issues:

        [0] 0xb12fb2000000002c, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum: 1461184347 - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0x980b0000000002e, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
    Objects: 1
        [0] 0x980b0000000002e, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum: 1461184347 - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0x4fac1c0000000032, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
    Objects: 1
        [0] 0x4fac1c0000000032, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum: 1461184347 - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xb12fb2000000002c, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
    Objects: 1
        [0] 0xb12fb2000000002c, type: 5, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum: 1461184347 - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0xa21a4e0000000030, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.283.0/windows/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)

Which is the same I see with VSG master. It's end of day now so I'll do another code review tomorrow and if I can't spot anything have a bash a implementing a different approach.

[AnyOldName3]

Those aren't the validation errors this PR attempts to fix. It's specifically the one mentioned in the PR description, and that check was added to the Vulkan SDK relatively recently, so you'll need 1.4.313 or later for it to be detected. The thing it's checking for has been illegal since Vulkan 1.0, though, which is why its valid usage number is only 67.