Fix the OpenGL backends on non-glx Linux platforms (and remove GLEW dependency)

[sulix]

There are a couple of issues preventing the OpenGL 1.1 and OpenGL ES 2.0 backends from working correctly on Linux systems which are using EGL rather than GLX. This most prominently affects Wayland systems, but can also affect X11 systems when SDL_VIDEO_FORCE_EGL=1, or presumably other setups like KMSDRM.

One issue is a crash due to eglMakeCurrent returning EGL_BAD_MATCH due to some combination of the SDL_GL_DEPTH_SIZE attribute being set after the window is created, and the enumeration (and thus context creation in test windows) of both OpenGL 1.1 and ES 2.0 profiles. There's definitely a bit of strange behaviour in SDL here, but since we're violating the requirement to do all of our SDL_GL_SetAttribute() calls before creating a window, I'm not sure it's technically a bug.

Nevertheless this is fixed (or at least worked-around) in commit 1.

The other issue is the GLEW depends on glXGetProcAddress, which only works on glx. The second patch drops the GLEW dependency altogether, replacing it with manual calls to SDL_GL_GetProcAddress().

[sulix]

(Whoops — this broke the Windows builds, because SDL_opengl.h includes windows.h, which conflicted with miniwin's definitions. Pushed a (hopefully) fixed version, alongside some clang-format fixes.)

[sulix]

Okay — I finally got this building on Windows, but it required a significant rework of the OpenGL 1.1 backend to move all of the OpenGL calls into a separate file, much like is done with the Direct3D9 backend. It seems to work here, but it's definitely a more drastic change than I'd expected.

The only other way I can think to do it is to provide our own, non-windows.h-including OpenGL definitions. (Which is sort of what GLEW is doing anyway.) That's possible, and maybe makes more sense if we wanted to dynamically load everything, but will depend on us matching the ABI exactly. So this seemed better for now.

[AJenbo]

I feel like at this point we should have our own internal types and avoid the bridge varians, vertex doesn't align with the real one anyway.

In it's current start the pr makes things feel a bit more fragile. Maybe we can do so as a follow up

[AJenbo]

Annoyingly the project setting only lets me squash merge so unfortunately both commits have been merged in to one.

If you could look at minimizing the use of D3DRMVERTEX in a follow up that would be much apriciated.

Then it could be structured like the real one:

typedef struct D3DRMVERTEX
{
	    D3DVECTOR position;
	    D3DVECTOR normal;
	    D3DVALUE tu, tv;
	    D3DCOLOR color;
}