player: reset last_av_difference if not applicable

Don't let stale values linger around.

Also fix a slightly related case in audio.c.
player: use backwards flag for seeking external tracks

Otherwise, the external track could end up at a position that's too
late.
player: make code more obvious

Or at least I think so.
video: improve decoder-based framedropping mode

This is the "old" framedropping mode (derived from MPlayer). At least in
the mplayer2/mpv source base, it stopped working properly years ago (or
maybe it never worked properly). For one, it depends on the video
framerate, which assume constant framerate. Another problem was that it
could lead to freezing video display: video could get so much behind
that it couldn't recover from framedrop.

Make some small changes to improve this.

Don't use the current audio position to check how much we are behind.
Instead, use the last known A/V difference. last_av_difference is
updated only when a video frame is scheduled for display. This means we
can keep stop dropping once we're done catching up, even if video is
technically still behind. What helps us here that this forces a video
frame to be displayed after a while. Likewise, we reset the
dropped_frames count only when scheduling a new frame for display as
well.

Some inspiration was taken from earlier work by xnor (see issue #620),
although the implementation turned out quite different.

This still uses the demuxer-reported (possibly broken) FPS value. It
also doesn't account for filters changing FPS. We can't do much about
this, because without decoding _and_ filtering, we just can't know how
long a frame is. In theory, you could derive that from the raw packet
timestamps and the filter chain contents, but actually doing this is
too involved. Fortunately, the main thing the FPS affects is actually
the displayed framedrop count.
video: actually count decoder-dropped frames

Normally, feeding a packet to the decoder should always return a frame
_if_ we received a frame before. So while we can't know exactly whether
a frame was dropped, at least the normal case is easily detectable.

This means we display something closer to the actual framedrop count,
instead of a bad guess.
player: rename "Late:" field to "SD:"

Follow up to previous commit.

This is probably confusing from a user point of view, since this field
shouldn't show up normally anymore. (Before this commit, it could show
up sporadically when a slow operation was performed during playback,
such as switching fullscreen.)
manpage: document terminal status line components

(The classic MPlayer documentation had this in separate files, but we
deleted them ages ago.)
mixer: always restore volume (even with pulse), don't unmute

Be less clever, and restore the volume state even with AOs like pulse,
which have per-application audio.

Before this commit we didn't do this, because the volume is global (even
if per-application), so the volume will persist between invocations. But
to me it looks like always restoring is less tricky and makes for easier
to understand semantics.

Also, don't always unmute on exit. Unmuting was done even with ao_pulse,
and interfered with user expectations (see #1107).

This might annoy some users, because mpv will change the volume all the
time. We will see.

Fixes #1107.
osdep: hack to fix build with low quality pthreads-w32 headers

When compiling semaphore_osx.c on win32, the following error happened:

/usr/i686-w64-mingw32/include/semaphore.h:160:6: error: unknown type name 'mode_t'

This is because this system header references symbols that are not
not defined anywhere. This is clearly a bug in pthreads-w32, but has
been known and unfixed since 2012, so add a hack to fix it.

We build semaphore_osx.c this way because it saves us an extra configure
check. On win32, Linux, etc. it's empty and contains
"#include <semaphore.h>" only.

Should fix #1108.
input: explain why we use semaphores

Also switch function names for better self-documentation.