Implement delayed depth readbacks, Vulkan only

[hrydgard]

This is a Vulkan implementation of some ideas from #16900, more specifically the mode where we just keep readbacks around until the next time the same "frame context" comes around, and if a readback is perform, we just return the old data immediately instead of reading new data, plus we schedule a read so we have the data next time.

The delay can be too large and Syphon Filter's lights are a bit flickery and weird since the Z values aren't exactly what the game expects when moving around, but performance is fantastic on mobile and they are at least roughly occluded right, so it's better than before at least. Anyway due to the problems I'm not really happy with this as-is for Syphon, but will likely work for Dangan Ronpa for example, as commented in the other issue by @unknownbrackets .

In this PR it's only enabled for depth readbacks, which are currently only enabled in Syphon anyway, but there will be further development of this before it can be merged, plus it needs to be implemented for OpenGL as well where possible using PBOs.

Changed it, now it's only enabled for the Dangan Ronpa readback, where it really has no discernable side effect, only a good speed boost.

I ran into trouble with my OpenGL implementation so postponing that.

Will later add an "as-fast-as-possible" mode, which will be slightly less safe and vulkan-only. This PR only implements the safest and longest-latency version of the idea.

[hrydgard]

I have experimentally found that it's possible to get the Syphon Filter lens flares to look near-perfect even with delayed feedbacks, with a little fudge factor - just multiply the read-back depths by 0.95 for example. Things still occlude just fine generally, while no longer flickering with movement. Quickly descending through the depravity levels of game-hackery though :)

Dangan Ronpa demo readbacks work great delayed.

[unknownbrackets]

While it's ugly, tbh if we're sure it's fine and looks about right across the game this is actually a type of game hack / compatibility flag I'm not so against. Since this is conceptually taking something we know how to do right (blocking) and applying an engine or series specific hack to make it still look the same but run faster.

That doesn't betray the goals of making the emulator capable of running all games well and solving underlying problems. It is ugly, though. Not saying it's not ugly.

That said, I feel like it must make some lights occlude early/late or something which I might be a bit less a fan of.

-[Unknown]

[hrydgard]

It does, but it's only really noticeable if you really look for it. However it's also possible there are some situations with thin walls where lights will shine through now when they didn't before - I didn't find any playing for a while, but it would not surprise me.

So before I do a compat hack for this, I want to see how good we can get it with fully async readbacks (that happen as soon as the GPU performs it, and doesn't wait until a guaranteed safe time the next time around the frame contexts).