Visualization, TKOpenGl - move out OpenGL ES support to dedicated library TKOpenGles

Currently TKOpenGl can be built either in OpenGL (desktop) and OpenGL ES modes.
This has a rationale - both share majority of source code and most interested target platforms support one of two.

However, some systems provide both OpenGL and OpenGL ES implementations at once.
This includes desktop Linux (Mesa) and Windows (with help of Angle library).
Therefore, it is proposed moving out OpenGL ES support to a dedicated library TKOpenGles to allow both being built at once.

The main objective is improved development and testing environment - so that changes in common code could be tested within a single build.
Applications will able to choose which library to use, though obviously full-featured desktop OpenGL should be always preferred when both implementations are available.
But some trickery applications would be able to select library at startup (for instance, when OpenGL drivers are unavailable on Windows, while Direct3D driver available and could be used by Angle).

The simplest way to support TKOpenGl + TKOpenGles configuration is reusing existing source code and just building two libraries with different compiler and linker flags.
In this case, both libraries will export the so-named classes of OpenGl package, but this should be fine as both libraries shouldn't be loaded at once anyway.
This is what this first patch is supposed to implement.

The next steps could be aimed on improving package structure.
One approach could be using macros to rename OpenGl_ classes to OpenGles_ within TKOpenGles library.
This, however, would require a considerable and not nice-looking code modifications across the whole package.

Another approach would be moving out the common code into a dedicated base library TKOpenGlBase.
Within this approach OpenGl_GlFunctions function table should be filled with both OpenGL ES and OpenGL functions at once.
This might be challenging, as it would require solving name collisions between glext.h, OpenGl_GLESExtensions.hxx and system-provided headers of OpenGL and OpenGL ES implementations.
OpenGl_Context sub-classes will be responsible for filling in this function tables from OpenGL or OpenGL ES implementations.
The drawback of this solution would be code paths practically unreachable for TKOpenGles (this should be relatively small amounts of code, mostly FFP-compatibility related), and some extra branching at runtime.
But in result packages structure would look cleaner, so that OpenGL-related code at application side or in extra packages can be build without direct dependency from system OpenGL libraries, and export unified OpenGL/OpenGL ES implementation without duplicating toolkits.