osc: Overhaul (wip)

Code reorganized to make layouts exchangeable
alternative test layout can be tested with
layout=slimbox
in the OSC config

timers are now used to properly animate the fade out when the
player is paused

duplicate seeks are discarded again
lua: wake up the core when setting OSD

The OSD is marked as changed, but the core isn't notified and this
doesn't immediately wakeup. (Possibly the OSD code should wakeup the
core instead, but maybe that woudl be overkill.)

Observed when using "mp.use_suspend = false" in the OSC, and pausing,
and moving the mouse pointer out of the window. The last part of the
fade remained visible for longer than intended.
player: use virtual time for --audio-file with ordered chapters

Apparently users prefer this behavior.

It was used for subtitles too, so move the code to calculate the video
offset into a separate function. Seeking also needs to be fixed.

Fixes #1018.
vo: eliminate a redundant variable

Originally, I probably had plans to allow NULL images to handle things
like the last frame case, but that idea was dropped later.
video: add VO framedropping mode

This mostly uses the same idea as with vo_vdpau.c, but much simplified.

On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).

This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.

On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.

"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
vo_opengl: if glfinish is used, also call it after swappping

It seems that at least on nvidia systems with composting disabled, we
can get it to block deterministically on the actual vsync event, which
should improve framedropping.
gl_common: add SGI_video_sync extension
vo_opengl: optional support for using GLX_SGI_video_sync

I'm not sure about the merit, though it does print nice numbers if debug
output is enabled.

Basically, this tries to achieve similar results as the glFinish()
business, but again it entirely depends on the drivers whether this
does anything meaningful, or whether it's actively harmful.
audio: add a mode to insert silence on severe A/V desync

This is probably a stupid idea, but it can't be denied that this
actually allows playing video without larger desync, even if video is
too slow.
video: add --display-fps switch to control framedrop FPS

Since the display FPS is currently detected on X11 only (and even there
it's known to be wrong on certain setups), it seems like a good idea to
make this user-configurable.
vo_wayland: fix redrawing logic

I must have broken it some time ago. The error case dealing with an
unavailable backbuffer was broken, and didn't handle memory management
correctly.
player: cosmetics: make code more compact
demux: remove unused function
demux: add option to control the readahead buffer by a duration value

--demuxer-readahead-secs now controls how much the demuxer should
readahead by an amount of seconds. This is based on the raw packet
timestamps. It's not always very exact. For example, h264 in Matroska
does not store any linear timestamps (only PTS values which are going
to be reordered by the decoder), so this heuristic is usually off by
several hundred milliseconds.

The decision whether to readahead is basically OR-ed with the other
--demuxer-readahead-packets options. Change the manpage descriptions
to subtly convey these semantics.
demux: enable thread by default

And change the defaults for the other queue options to reduce latency.
x11: use xrandr to retrieve display refresh rate

Drop use of the ancient XF86VM, and use the slightly less ancient Xrandr
extension to retrieve the refresh rate. Xrandr has the advantage that it
supports multiple monitors (at least the modern version of it).

For now, we don't attempt any dynamic reconfiguration. We don't request
and listen to Xrandr events, and we don't notify the VO code of changes
in the refresh rate. (The later works by assuming that X coordinates map
directly to Xrandr coordinates, which probably is wrong with compositing
window manager, at least if these use complicated transformations. But I
know of no API to handle this.)

It would be nice to drop use of the Xinerama extension too, but
unfortunately, at least one EWMH feature uses Xinerama screen numbers,
and I don't know how that maps to Xrandr outputs.
build: drop check for XF86keysym.h

This is always included in the Xorg development headers. Strictly
speaking it's not necessarily available with other X implementations,
but these are hopefully all dead.
build: use pkg-config for xscreensaver
x11: fix memory leaks

Oh, we have to free this stuff. OK.
video: take refresh rate changes into account

This works only on X11, and only if the refresh rate changes due to the
window being moved to another screen (detected by us). It doesn't
include system screen reconfiguration yet.

This calls VOCTRL_GET_DISPLAY_FPS on every frame, which makes me uneasy.
It means extra thread communication with the win32 and Cocoa backends.
On the other hand, a frame doesn't happen _that_ often, and the
communication should still be pretty cheap and fast, so it's probably
ok.

Also needs some extra fuzz for vo_vdpau.c, because that does everything
differently.