player: better cache status on status line

The cache percentage was useless. It showed how much of the total stream
cache was in use, but since the cache size is something huge and
unrelated to the bitrate or network speed, the information content of
the percentage was rather low.

Replace this with printing the duration of the demuxer-cached data, and
the size of the stream cache in KB.

I'm not completely sure about the formatting; suggestions are welcome.
Note that it's not easy to know how much playback time the stream cache
covers, so it's always in bytes.
demux: reset idle state on seeks
demux_lavf: don't reject av:// if cache is enabled

Enabling the cache doesn't make much in this situation, but there's also
no reason not to reject it.
player: slightly better cache underrun detection

Use the "native" underrun detection, instead of guessing by a low cache
duration. The new underrun detection (which was added with the original
commit) might have the problem that it's easy for the playloop to miss
the underrun event. The underrun is actually not stored as state, so if
the demuxer thread adds a new packet before the playloop happens to see
the state, it's as if it never happened. On the other hand, this means
that network was fast enough, so it should be just fine.

Also, should it happen that we don't know the cached range (the
ts_duration < 0 case), just wait until the demuxer goes idle (i.e.
read_packet() decides to stop). This pretty much should affect broken or
unusual files only, and there might be various things that could go
wrong. But it's more robust in the normal case: this situation also
happens when no packets have been read yet, and we don't want to
consider this as reason to resume playback.
player: dynamically change cache wait times

Remove the hardcoded wait time of 2 seconds. Instead, adjust the wait
time each time we unpause: if downloading the data took longer than its
estimated playback time, increase the amount of data we wait for. If
it's shorter, decrease it.

The +/- is supposed to avoid oscillating between two values if the
elapsed time and the wait time are similar. It's not sure if this
actually helps with anything, but it can't harm.
vo_opengl: fix shader

Regression since commit f14722a4. For some reason, this worked on
nvidia, but rightfully failed on mesa.

At least in C, the ## operator indeed needs two macro arguments, and
you can't just concatenate with non-arguments.

This change will most likely fix it.

CC: @bjin
vo_opengl: don't pass (char*)NULL as %s printf argument

glGetString(GL_SHADING_LANGUAGE_VERSION) can return NULL; I suppose this
happens on legacy OpenGL, while all the other fields are guaranteed to
exist.
player: don't sort a NULL list

This can occur if the directory does not have any files in it which
causes files to never be non-NULL for qsort.
player: simplify chapter display name code

The display name is always recomputed, so we can always toss the input
name.
tv: initialize frequencies to 0
posix: use STD*_FILENO constants

Rather than "magic" numbers, use meaningful constant names provided by
unistd.h.
audio: restore old speed change behavior

Don't attempt to resync after speed changes. Note that most other cases
of audio reinit (like switching tracks etc.) still resync, but other
code paths take care of setting the audio_status accordingly.

This restores the old behavior of not trying to fix audio desync, which
was probably changed with commit 261506e3.

Note that the code as of now wasn't even entirely correct, since the A/V
sync values are slightly shifted. The dsync depends on the audio buffer
size, so a larger buffer size will show more extreme desync. Also see
mplayer2 commit 213a224e, which should fixed this - it was not merged
into mpv, because it disabled audio for too long, resulting in a worse
user experience. This is similar to the issue this commit attempts to
fix.

Fixes: #1042 (probably)
CC: @mpv-player-stable
player: update cache state only if requested

Add a mechanism to the client API code, which allows the player core to
query whether a client API event is needed at all. Use it for the cache
update.

In this case, this is probably a pure microoptimization; but the
mechanism will be useful for other things too.
command: export demuxer cache info properties
options: more detailed output for --vf-... error message