Vulkan: Always keep `vkWaitForFences` alive in DCE
Vulkan: Always keep `vkWaitForFences` alive in DCE

Previously, `vkWaitForFences` was kept kept alive by a forward dependency from
the queue submission that signaled the fence. However, this misses the following
case:
  1. Queue Submission 1 signals a semaphore (ALIVE)
  2. Queue Submission 2 waits on the semaphore, and signals a fence (DEAD)
  3. vkWaitForFences

In this case, the queue submission that directly signaled the fence is dead, so
the vkWaitForFences would also be dead. However, vkWaitForFences is indirectly
synchronizing Queue Submisison 1 with the commands after vkWaitForFences, so it
cannot be safely killed.

This hack will unfortunately cause false dependencies. In the example above,
once vkWaitForFences is alive, Queue submission 2 must also become alive, so
that the fence gets signaled (and the work in Queue submission 2 may pull in
other dependencies). This problem will be mitigated once we have subcommand
level DCE (WIP), since this will allow us to keep the vkQueueSubmit without any
of the actual commands inside the queue submit. The full resolution of this
problem will require proper synchronization dependencies (WIP).

pmuetschard/gapid,google/gapid,google/agi,google/agi,google/gapid,google/agi,Qining/gapid,Qining/gapid,google/agi,google/agi,pmuetschard/gapid,google/gapid,google/gapid,pmuetschard/gapid,google/gapid,google/gapid,google/agi,pmuetschard/gapid,Qining/gapid,google/gapid,pmuetschard/gapid,pmuetschard/gapid,Qining/gapid,Qining/gapid,google/agi,Qining/gapid,pmuetschard/gapid,google/gapid,pmuetschard/gapid,Qining/gapid,google/agi,Qining/gapid