Each immediate viewport waits for vsync by itself

[valadaptive]

Describe the bug

This seems to be the root cause behind a lot of immediate viewport-related issues (see #4963 and maybe #5145).

Basically, whenever an immediate viewport is rendered, swap_buffers (or its wgpu equivalent) is called. If vsync is enabled, swap_buffers will block all further graphics API calls until vsync (see https://stackoverflow.com/questions/29617370/multiple-opengl-contexts-multiple-windows-multithreading-and-vsync). If you call swap_buffers on two different windows with nothing in between the two calls, this is fine because you're not submitting any work to the GPU in-between. With show_viewport_immediate, however, the entire viewport is rendered (and the buffers swapped) before any further rendering work is done.

This means that with 2 total windows open, the application will run at 1/2 the FPS. With 3 windows, 1/3 FPS, and so on.

I believe that moving the buffer swaps to all occur at the same point will fix this issue, but I'm not sure whether that will mess with the way immediate viewports work.

To Reproduce
Steps to reproduce the behavior:

1. Run egui_demo_app
2. Open the "Extra Viewport" demo. Notice how at 60 FPS, the extra viewport adds an extra 16ms to the frame time, and the FPS is now exactly 30. That's suspicious...

Expected behavior

While immediate viewports are explicitly described as blocking, I don't think anyone expects them to block for an entire extra frame.

Additional context
This behavior occurs in both the glow and wgpu backends. I haven't dug into the call stack for the wgpu backend yet.