osd: reset OSD progression display

The code for showing OSD progression ('P' key) set a flag in a
mp_osd_msg_t to do its work. OSD messages can be re-used for completely
unrelated purposes (it's unclear why), so this has to be reset if an
old OSD progression message is reused for something different.

Be sure to reset the full message. Remove the messy code for searching
the OSD stack. Use the existing rm_osd_msg() function to remove the old
message (if there was one), and always create a new message. The new
code should be functionally equivalent to the old code. The "started"
flag wasn't reset before, but since the time is always overwritten, this
might be actually more correct.
timer: remove timer_name

This was unreferenced and useless.
core, timeline: don't keep separate stream field

The timeline code kept pairs of stream and demuxer references around.
The reference to the stream is redundant, because it can be accessed
through the demuxer.

Simplify the code by removing the redundant stream reference.

Also, set mpctx->stream to the current segment when using timeline.
Fix a small memory leak in tl_matroska.c introduced earlier.
command: remove sub_log command

Not very useful, and introduced special cases. Just get rid of it, can
be reintroduced if in a better way if someone misses this feature.
command: remove sub_remove command

This messes deeply with the subtitle bookkeeping data structures, and
would have to be reimplemented anyway.

It's not sure what this was even useful for. Possibly for slave mode.
fix shader identation
use uniform array for input textures/sizes

Also fix the naming to the conventions used otherwise in the code.
fix one use of texture()
redo extension loading

- Provide a more "precise" table of GL functions/extensions
- They are separated in sections, because repeating the extension or
  GL version per function is seriously annoying
- Tried to confirm the GL version of every function (didn't do the same
  with constants, except for sRGB stuff)
- Legacy crap should still work, right down to OpenGL 1.1
- New way of querying extensions inside mplayer (MPGL_CAP_* constants)
- Kind of rewrote context creation entry points too: now even vo_gl use
  the create_mpglcontext() function, and you pass in required
  capabilities instead of the version number
rename mpgl functions

This is Better (tm).
make trying GL 2.1 default

As it is, it will try to create a GL 3 context, and if that fails, try
to continue with a legacy context.
?
some crap to deal with the GL3/GL2 window creation fallback

- Do not retry the fallback stuff on an existing window (e.g. mplayer
  reconfigures window -> trying to create a GL3 context on a GL2 ctx)
- If GL3 creation fails, we must destroy the window. This is all X11's
  fault, because GL3 requires GLX 1.3, while GL2 can do with older GLX.
  We could avoid this if we made GLX 1.3 mandatory for everything.
disable scalers if floating point textures unavailable

There are no other floating point texture uses, probably.
Don't check FBO formats provided by user options (the default is safe,
and otherwise it's the user's fault).
don't disable srgb framebuffer if it's not set in the first place

This was used to make the code shorter, and was ok in 3.0 where srgb
framebuffers are always available. In 2.1 Mesa this caused GL errors.
reject suspected software renderers in vo_gl3

- Copy logic from vo_gl.c
- No good error message yet (should be printed somewhere under
  mpgl_create_window())
- Fix a typo from previous commit (wth?)
blacklist "Mesa X11" as software renderer
print error message if GL context is rejected as software rendering
fix logic for disabling scaling with FBO
avoid flicker on window creation by reusing auto detection

If GL3 context creation fails, we created a new window for the GL2
context. This was visible as flicker and rather annoying. Avoid this by
reusing the state from auto-detection. Auto-detection creates an
invisible window to test context creation, so there's no flickering
anymore. The visible window will be created with the working context
creation method.

This is all a bit sketchy:
- does auto-detection actually work, or could it happen that a new
  window has different attributes? (The hidden window is always
  destroyed.)
- can vo backend reinit fail when run a second time (after uninit)?