Introduce abstraction layer for SDL library

Primary goal is to allow hardware acceleration - this is something that is frequently asked and, while this is not "must-to-have" it is certainly "nice-to-have". In general, it should give us:

Better performance, potentially making a difference on low-end portable devices (for PC's improvement would be neglible)
Cleaner code, since C API of SDL is often quite verbose and requires specific sequence of operations.
Allow modders to use fully functional formats, e.g. RGBA images for combat images

Abstraction Layer

[x] Create classes to hide SDL internals
[x] Make Geometries accessible to library code (for less awful loading of UI-related objects info)
[x] Add Color class to Geometries. Consider whether underlying type should be float or uint8_t.
[x] Refactor existing UI code to remove direct access to SDL functions
[x] Remove direct usage of SDL_Event's from UI code
[x] Remove access to SDL_Color from non-SDL classes
[x] Remove remaining references to SDL_Surface's, mostly from infowindow code
[ ] Make screen/renderer/window global variables into a members
[ ] Split sound, music and video handlers into interface+implementation
[ ] Merge GH and CCS?
[ ] Convert Graphics into RenderHandler
[ ] Load all graphical files via RenderHandler

Hardware acceleration support:

[ ] Introduce Texture class for hardware-accelerated surfaces
[ ] Introduce Image Proxy class that can track changes to SDLImage and query Texture updates
[ ] Introduce HardwareCanvas class that performs rendering on a render target surface
[ ] Refactor GuiHandler class to allow hardware-accelerated SDL mode that performs rendering via textures
[ ] Attempt to use hardware-accelerated rendering

Support for HD Edition / upscaled graphics

TODO

vcmi / vcmi

Introduce abstraction layer for SDL library #1263

Abstraction Layer

Hardware acceleration support:

Support for HD Edition / upscaled graphics