vo_opengl: simplify the case without texture_rg

If GL_RED was not available, we used GL_ALPHA. But this is an
unnecessary complication, and it's easier to use GL_LUMINANCE instead.
With the latter, a texture will return the .r component set, and as long
as the shader doesn't look at the other components, the shader doesn't
need any changes.

Some of the changes added in 0e8fbdbd are now unneeeded.

Also, realign the entire gl_byte_formats_legacy table.
vo_opengl: minor simplification in function loader

Don't force every entries without functions to define a dummy array.
x11: minor improvements

Always include the window position in winrc, even if the window
embedded. This should give the correct positions for things which still
interact with global coordinates, such as the xrandr code.
x11: fix mysterious issue with window embedding on OpenBox

For some reason, when using window embedding, and the window manager is
OpenBox, calling XSetWMNormalHints() before the window is mapped, the
initial window position will be off. It leaves some vertical space,
instead of placing it on the top/left corner. Suspiciously, the vertical
space is as much as a the height of normal window decoration.

I don't know what kind of issue this is. Possibly an OpenBox bug, but
then this happens even if the override-redirect flag is set. (This flag
basically tells the X server to ignore the window manager. Normally we
don't set it.) On other window managers, it works fine. So I don't know
why this is happening.

But this is easy to workaround. XSetWMNormalHints() isn't needed at all
if embedding.

Should fix #1235.
vo_opengl, x11: make legacy context warning not an error

Really, this doesn't actually matter. It's printed as error only because
it was once thought to be an mostly unneeded fallback, but it turned out
this is still frequently needed, and users are getting confused.
vo_opengl: simplify some aspects of the GL function loader
vo_opengl: do not use 4x3 matrix

This was a nice trick to get the mpv colormatrix directly into OpenGL,
because the memory representation happened to match.

Unfortunately, OpenGL ES 2 doesn't have glUniformMatrix4x3fv().

Even more unfortunately, the memory representation is now incompatible.
It would be nice to change it, but that would mean getting into a big
mess.
vo_opengl: clean up GL ES function loading

Previously, this was sort of messed together with desktop OpenGL
loading. Add explicit support for ES, and clean up the mess. Also sort
the function arrays alphabetically (at least most of them).

In some cases, add functions to multiple sections. This keeps the number
of sections down.

Don't check for GL_ARB_vertex_array_object. This feature must be used in
OpenGL 3 core, while it may be not available at all in earlier versions,
and not using it if it's available as extension only has no advantages.

This commit also considers GLES 2, because actual support for it will be
added with a later commit.

Also get rid of some MPGL_VER() uses (see some commits ago).
vo_opengl: disable some unavailable features under ES

There are probably many more which I overlooked.
vo_opengl: mess with PixelStorei state management

This is needed for GLES 2 support. GLES 2 doesn't support
GL_UNPACK_ROW_LENGTH, and we shouldn't even use this constant, since a
GLES implementation could raise an error.

So set it only if neccessary, and leave it in the default state
otherwise. This also smuggles in a ES 2 fallback for glUploadTex(),
and querying an extension relevant for ES 2. For the alignment state
(GL_[UN]PACK_ALIGNMENT) do the same for symmetry. All 4 states
(alignment/rows x pack/unpack) are now assumed to be in their initial
states by default.

Also redo the PixelStorei handling in the function table. I could rebase
this, but look at the commit time.
vo_opengl: add GLES 2 support

Rather basic support. Almost nothing works, and even if it does, it's
bound to be inefficient (due to texture upload). This was tested with
the nVidia desktop binary drivers, which provide GLES 2 support only.
However, nVidia is not known to be very strict about OpenGL, and the
driver is very new too, so the vo_opengl code will have bugs too.
vo_opengl: unbork

Probably.

The version handling schema is a bit strange (and led to a tricky and
obvious bug), but it's quite similar to what OpenGL does at some places,
so I blame the OpenGL standard.