VideoCommon: Remember to flush command buffers after multiple EFB copies

[TellowKrinkle]

When using deferred readbacks, there was a system set up to not flush command buffers if multiple EFB copies were issued in succession, but it only ever checked whether it needed to flush when an EFB copy was issued, so things ended up looking like this (CPU/GPU activity traces from Metroid Prime 3 Elysia @ 3x IR):

After the change, which also rechecks whether it needs to flush after each draw:

Brings the scene in question from 53fps to 60fps on my laptop.

Side note, counter is updated after every EFB copy, so if the cutoff was 10 and the following was issued:
EFB Copy, 4 Draws, EFB Copy, 4 Draws, EFB Copy, 4 Draws, EFB Copy
there would be no flushes in the middle (or at the end).

No flush at the end is definitely a bug, but is no flushes in the middle a bug? I went back and forth on this, and in the end settled on "no" (though the above screenshot is actually from when I was on "yes", you can see one extra command buffer submission in the middle of the readbacks because of it), but some outside input would be nice.

[JMC47]

This does seem to generally increase performance in Metroid Prime Trilogy with deferred readbacks, but the gains tend to vary per area. Elysia is the big winner for sure.