This is now a separate type from spritetype which contains an actor pointer instead so that sprite display can be handled without requiring a static sprite array.
Due to dependencies on initializing some data in app_init it was not possible to cleanly set up the fonts.
This adds a game-side function for loading the entire palettes before starting with the texture data and another one for loading game-side texture data.
This now allows fully setting up the palettes before starting with the textures and to fully set up the textures before reading the .def files.
All this is needed because to properly initialize, the fonts need to be able to access the fully initialized texture state, including replacements and hires substitutions from the .def files.
Since these do not fully get processed sequentially the contents need to be preserved until needed.
This required getting rid of the global tsprite array. Polymost still uses a static vatiable, though, but this is only accessed in polymost-exclusive code.
This was by far the messiest game, there's two reasons for this.
First, the portal links do not need to be in an actual portal sector, so they cannot be used to detect portal sectors.
Second, the game moves portals in place, so all offsets are (0,0,0) so that not even these can be used for detection.
The only working method is the super-complicated original way to look up portals at run time, just being done at map start.
Having static portal links should reduce the render glitches quite significantly because the renderer knows now which sectors belong to a portal and can use this information to ensure proper processing.
Unlike the other games these are so poorly defined that the engine has to rely on the original fudging to pick the proper portal to link to. As a result they are just as limited as they always were.
In addition all the portal search code had to be reinstated.
* Blood had this right. It makes sense that the horizon be based around as it's easier to work with.
* Removed all associated game math to deduct default horizon of 100 when doing weapon zvel etc, meaning actual horizon can just be used.
* Re-did return to center function to work on the already converted pitch. Return speed should be 1:1 with previous code.
* For Duke/SW, we continually apply `SB_CENTERVIEW` only if it was previously a toggled action, similar to Blood.
* For SW, we remove two SW-specific bits (`PF_LOCK_HORIZ` and `PF_LOOKING`) that are no longer needed.
* For Duke, we remove `return_to_center` and just use the `SB_CENTERVIEW` action bit as required.
* For `sethorizon()`, feature set and adjustment speeds are an averaged out accumulation across Duke/SW:
** GameTicRate is factored in for adjustment decisions to provide consistency for SW being the faster game.
** Adjustment amounts are half way between Duke/SW.
