Deadlock when waiting on the queue

[artem-lunarg]

This test reproduces the issue:

TEST_F(PositiveSyncObject, TwoQueueSubmitsWaitBeforeSignal) {
    AddRequiredExtensions(VK_KHR_TIMELINE_SEMAPHORE_EXTENSION_NAME);
    AddRequiredFeature(vkt::Feature::timelineSemaphore);
    all_queue_count_ = true;
    RETURN_IF_SKIP(Init());

    if (!m_second_queue) {
        GTEST_SKIP() << "2 queues are needed";
    }
    vkt::Semaphore semaphore(*m_device, VK_SEMAPHORE_TYPE_TIMELINE_KHR);
    m_default_queue->SubmitWithTimelineSemaphore(vkt::no_cmd, vkt::wait, semaphore, 1);
    m_second_queue->SubmitWithTimelineSemaphore(vkt::no_cmd, vkt::signal, semaphore, 2);
    m_default_queue->Wait();
}

The scenario is almost identical to #7904 but waiting on a single queue instead of vkDeviceWaitIdle.

This use case looks more tricky comparing to a deadlock with vkDeviceWaitIdle. In the latter case it was enough to Notify() all the queues. In the above test it's not enough to notify m_default_queue, because it depends on m_second_queue, and somehow we need to initiate forward progress on the second queue too. But it's also incorrect to initiate forward progress on all the queues. In the general case this can retire the queues that are not in the dependency chain and can legally be pending after the wait.

[artem-lunarg]

TODO: add a negative test that adds the third queue that does not interact with the above two queues and is still pending after the Wait(). We get an error when trying to delete a resource used by the third queue after the Wait().