Since this deletes the resolved elements one by one and needs to start at the front to ensure consistency, it is better to reverse the order so that the deletions take place at the end of the list which requires a lot less data movement.
On Total Chaos this slowed down texture setup to the point where the mod was basically unlaunchable.
Between creation and resolving the texture manager will resort the textures and after that the old ids are no longer valid. The textures themselves have the correct one, so that should be used.
FDummyTexture had a big problem: Whenever it was accessed by accident it crashed the app because it wasn't fully implemented.
What it should do is return empty pixels of the given size, and an unextended FImageTexture is doing just that.
* split up FMultiPatchTexture into a builder class and the actual image source.
* since images can now be referenced by multiple textures the old redirection mechanism has been removed. It can be done better and less intrusive now. Simple single patch textures already directly reference the underlying patch image now.
* allocate all image source related data from a memory arena. Since this is all static this makes it a lot easier to free this in bulk.
