[Impeller] Add present wait latch.

[jonahwilliams]

It turns out the fixing #47249 revealed further bugs: we were actually overwriting previous presents and dropping frames, which was what the forward progress error was hinting. Once this problem is fixed, we started hitting present timeouts or overdraw of swapchain images.

The fix for this is that we shouldn't even ask for a swapchain image until after we've called present, which actually wasn't tracked with anything.

The error:

A Dart VM Service on Pixel 6 Pro is available at: http://127.0.0.1:62491/_N4PSEPUtA0=/
The Flutter DevTools debugger and profiler on Pixel 6 Pro is available at: http://127.0.0.1:9102?uri=http://127.0.0.1:62491/_N4PSEPUtA0=/
W/OnBackInvokedCallback(19160): OnBackInvokedCallback is not enabled for the application.
W/OnBackInvokedCallback(19160): Set 'android:enableOnBackInvokedCallback="true"' in the application manifest.
W/vulkan  (19160): dequeueBuffer timed out: Function not implemented (-38)
E/flutter (19160): [ERROR:flutter/impeller/base/validation.cc(49)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not acquire next swapchain image: Timeout
E/flutter (19160): [ERROR:flutter/shell/gpu/gpu_surface_vulkan_impeller.cc(64)] No surface available.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie or stuartmorgan on the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[bdero]

Honestly this is still wracking my brain, but it's clearly safe.

[bdero]

Actually, I think I get it... The queue submission thread is speeding back around to a frame that hasn't presented yet. But we only wait for the acquire fence (which fires after the previously submitted queue workload has finished, but before the frame has been presented). When this happens, we'll end up starting a second frame workload for the same FrameSynchronizer that shares the same semaphores for PresentKHR and AcquireNextImageKHR.