This will mostly ensure that each patch used for composition is only loaded once and automatically unloaded once no longer needed.
So far only for paletted rendering, but the same logic can be used for true color as well.
This was done to make reviewing easier, again because it is virtually impossible to search for the operators in the code.
Going through this revealed quite a few places where texture animations were on but shouldn't and even more places that did not check PASLVERS, although they were preparing some paletted rendering.
As a bonus this already fixes several bugs caused by the botched texture scaling implementation the original texture manager came with.
System cursors are currently disabled because they rely on functionality that needs to be moved to different classes.
The main reason is to unify the portal hierarchy again. The split into a hardware independent and a hardware dependent part turned out to be unnecessary and complicated matters.
Another issue was that the new stencil setup code was having a few subtle problems, so this recreates the original ones with indirect API calls.
* Colors can npw be defined per sidedef, not only per sector.
* Gradients can be selectively disabled or vertically flipped per wall tier.
* Gradients can be clamped to their respective tier, i.e top and bottom of the tier, not the front sector defines where it starts.
The per-wall colors are implemented for hardware and softpoly renderer only, but not for the classic software renderer, because its code is far too scattered to do this efficiently.
An exception is made for the sprite drawer which needs to call this in the worker thread on some occasions for as-yet unprocessed sectors.
This case may not alter the cache to avoid having to add thread synchronization to it.
The main reason for this change is that pointers to such manipulated sectors can now be considered static in the renderer.
Due to them being short lived local buffers it was not possible to carry them along with the render data for information retrieval.
This is not flexible enough. There was already one place where this was not supposed to go through the render state.
The new interface allows more general use of the contained buffer objects.
The original idea was to let Vulkan do this completely differently, but if that comes to pass it should be done without having generic data maintenance code on the API side.
