Texture and vertex caching and invalidations

[[Unknown]]

Different games have different requirements here, different misuses, and different signals to the emulator.

To define what we have now:
* Vertex cache: caches only larger vertex arrays, but works well. Causes minor glitches in a few games. Turns on and off.
* Texture cache: caches all textures. Works fairly well but causes some minor glitches or slowdowns in a few games. Sometimes uses too much VRAM. Not configurable.
* FBO cache: not exactly a cache, but similar to one. Uses up VRAM too, but kept mostly in check. Controlled by buffered rendering, sorta.

Games provide the following signals:
* GE block transfers: currently invalidates textures only. Not configurable. Could potentially do something with FBOs and vertices.
* GE texture flush: seems to be generated entirely too often, but might be a signal to rehash textures. Currently ignored.
* cache CPU instruction: indicates updates in the Icache, Dcache and secondary cache. Currently ignored.
* sceKernelDcache*: indicate updates to the Dcache. Not configurable. Works reasonably well but can slow down games, and many lazy games abuse it.
* Uncached memory addresses: indicates slower access to uncached memory. May indicate a more volatile resource. Currently ignored.

We also have the following mechanisms on top:
* Hashing: textures and vertices are hashed using progressive backoff. Upside is this detects changes, downside is it causes "jumping" and eats time. Not configurable.
* Decimation: all three are deleted if they are not used within X frames. This is mainly to save VRAM, but for some devices/games it's not enough. Not configurable.

I'm not a fan of per-game options, or incredibly detailed options (at least in the UI), but there seem to be many things we could make more controllable here. What I'm not sure is what people would want to configure. For example, a "high" (max speed, max glitches), "medium" (e.g. the current way), and "low" (slower, minimum glitches) might make sense.

Further options to control decimation for VRAM use might make sense too. For example, a mobile device with tons of RAM could decimate less often to try to maximize speed. Another mobile device or cheaper desktop card could decimate more often to keep VRAM free.

Any thoughts?

-[Unknown]