[Frame Looping] Manage fences that are signaled/waited-on during the looping frame

[nickdriscoll-lunarg]

This PR is based on top of #2935 so it will need to be merged first.

In the case of naive looping, it is easy to see how a fence can be double-signaled or double-waited-on, so we need to handle those situations.

Regarding a fence that is used during the looping frame, there are three cases:

1. The fence is signaled as many times as it is waited upon
2. The fence is signaled more times than it is waited upon
3. The fence is signaled fewer times than it is waited upon

In the first case, no special handling is needed, as the final fence operation will put the fence in the state that the first fence operation expects.

In the second case, we need to synthetically wait-on the fence so that it's in the unsignaled state at the start of the next iteration of the looping frame.

In the third case, we need to synthetically signal the fence so that it's in the signaled state at the start of the next iteration of the looping frame.

[antonio-lunarg]

Mmh.. what if the collected fences belong to different devices?
Maybe it is not that common as a case, but the replay consumer is grouping various things per-device to avoid this kind of issue.

[nickdriscoll-lunarg]

Good catch that my code assumes a single VkDevice. I should be able to extend it to handle multiple devices without too much suffering.

[CLAassistant]

All committers have signed the CLA.

[antonio-lunarg]

Make sure to squash all commits together. Anyway, LGTM.