Replace SGE for backgrounds and right menubar

[morganchristiansson]

SGE (SDL Graphics Extension), a abandoned 3rd party vendored library is used in s25edit to draw all triangles in 2D software.

Outside of drawing the triangles & terrain it's used for:

• drawing background images for splash and main menu screens.
• drawing right menubar with 270deg rotation.

This PR converts those to vanilla SDL.

Later when we replace SGE with OpenGL for drawing triangles&terrain, we can delete SGE and use this method to keep drawing it as 2D using SDL.
Much later the UI should probably be drawn as OpenGL entirely.

[morganchristiansson]

Remaining SGE usage is all in CSurface.cpp

CSurface.cpp
10:#include "SGE/sge_blib.h"
11:#include "SGE/sge_surface.h"
22:static bool sgeLockOff = (sge_Lock_OFF(), true);
46:    sge_PreCalcFadedTexturedTrigonColorKeys(dest, p1.x, p1.y, p2.x, p2.y, p3.x, p3.y, source, rect.x, rect.y, right,
58:    sge_FadedTexturedTrigonColorKeys(dest, p1.x, p1.y, p2.x, p2.y, p3.x, p3.y, source, rect.x, rect.y, right, rect.y,
857:            sge_TexturedTrigon(display, p1.x, p1.y, p2.x, p2.y, p3.x, p3.y, Surf_Tileset, upper.x, upper.y, left.x,
864:                sge_TexturedTrigon(display, p1.x, p1.y, p2.x, p2.y, p3.x, p3.y, Surf_Tileset, upper2.x, upper2.y,
867:                    sge_PreCalcFadedTexturedTrigonColorKeys(display, p1.x, p1.y, p2.x, p2.y, p3.x, p3.y, Surf_Tileset,
872:                    sge_FadedTexturedTrigonColorKeys(display, p1.x, p1.y, p2.x, p2.y, p3.x, p3.y, Surf_Tileset, upper.x,
878:                    sge_PreCalcFadedTexturedTrigon(display, p1.x, p1.y, p2.x, p2.y, p3.x, p3.y, Surf_Tileset, upper.x,
882:                    sge_FadedTexturedTrigon(display, p1.x, p1.y, p2.x, p2.y, p3.x, p3.y, Surf_Tileset, upper.x, upper.y,

Not a lot.
A simple OpenGL replacement is not too hard.
But maybe best implementation is not just replacing sge calls with OpenGL but to add TerrainRender.cpp and align with s25client. Maybe one day they can use shared classes.

[morganchristiansson]

Could also go straight to OpenGL without the interim step at vanilla SDL tho.
But drawing backgrounds isn't best use of OpenGL.
A single PR for converting to OpenGL might be most efficient but it can end up a sprawling beast to review, with backgrounds, UI components, terrain rendering. Or can do each of these split as separate PRs.
UI components is quite large by itself.
Terrain rendering can have multiple levels of completion. Like current zoom changes triangle coordinates, but glScale() can do the zoom entirely in GL without recalculating triangle coordinates.
Mouse cursor can be drawn with OpenGL.
Brushes, sprites.
Can use camera viewport for showing only parts of map.
etc
rabbithole goes deep.
s25client is already doing all of these.

Idea here tho is to follow up with terrain rendering as OpenGL which is biggest struggle for vanilla SDL.

[Flamefire]

We make CSurface more and more messy: A class used as a namespace from the old C days. Because now it feels we simply move parts of SGE to CSurface without any real improvement.

But TBH: As the editor works, why spend time here unless we do actually want to extent it with something worth doing?