demux_playlist: redirect ASF streaming to mmsh://

I'm not sure if this could be done in libavformat instead. Probably not,
because libavformat doesn't seem to have any mechanism for trying one
protocol and reverting (or redirecting) to another one if needed.

This commit is sort of a hack too, because it redirects the URL by
pretending the http:// link is  a playlist containing the mmsh:// link.

The list of mime types is borrowed from MPlayer (which has completely
different code to handle this).
demux_lavf: mark as seekable if protocol supports seeking by time

Basically, this will mark the demuxer as seekable with rtmp* and mmsh
protocols. These protocols have network-level time seeking, and whether
you can seek on the byte level does not matter.

Until now, seeking was typically only enabled because of the cache, and
a (nonsensical) warning was shown accordingly.

It still could happen that the server doesn't actually support thse
requests (or simply rejects them), so this is somewhat imperfect.
demux_lavf, stream_lavf: drop local buffers on time-seeks

There was chance that some data was left in various local buffers after
time-seeks. Probably doesn't actually matter.
options: accept --audio-channels=auto

This sounds much more intuitive, while "empty" was a bit of a WTF.
player: improve exit message in some scenarios

If you played e.g. an audio-only file and something bad happened that
interrupted playback, the exit message could say "No files played".
This was awkward, so show a different message in this case.

Also overhaul how the exit status is reported in order to make this
easier. This includes things such as not reporting a playback error
when loading playlists (playlists contain no video or audio, which
was considered an error).

Not sure if I'm happy with this, but for now it seems like a slight
improvement.
player: change framedrop display in the status line

Hopefully less confusing, and hopefully doesn't exceed the terminal
width in any situation.
ao_alsa: don't make snd_pcm_hw_params_set_buffer_time_near() error fatal

Apparently this can "sometimes" return an error. In my opinion, this
should never return an error: neither the semantics of the function,
nor the ALSA documentation or ALSA sample code seem to indicate that
a failure is to be expected. I'm not perfectly sure about this though
(I blame ALSA being a weird, big, underdocumented API).

Since it causes problems for some users, and since there is really no
reason why we should abort on such an error, turn it into a warning.

Fixes #1231.
osdep: potentially fix compilation on OpenBSD

The <pthread_np.h> header expects that <pthread.h> was already included.
We were including <pthread.h> only later via our threads.h.
sub: be more flexible about changes to how subtitles are rendered

For example, if --force-window is used, and video is switched off during
playback, then you need to redecide the rendering method to get subs
displayed correctly.

Do this by moving the state setup code into a function, and call it on
every frame.
command: don't require whitespace before ';' or '#'

This change is probably too simplistic, but most things appear to work,
so I don't care about that now.

Fixes #1232.
sub: remove osd_get_sub()

Trades one strange thing against another, but seems slightly less
strange.
cache: don't relay STREAM_CTRL_AVSEEK if it's unsupported

Thanks to STREAM_CTRL_HAS_AVSEEK, we actually know whether CTRL_AVSEEK
is implemented at all, and we can avoid a blocking wait on the cache if
demux_lavf sends CTRL_AVSEEK even if it won't wait. I'm hoping this
can't currently happen, but why hope if we can explicitly prevent it.
It'll make us more robust against future changes in libavformat.
build: fix 'ar' invocation when cross-compiling

This shouldn't use the host's 'ar' when building static libs. It only
worked until now because Linux 'ar' is usually built with PE support.

Couldn't confirm whether it works, because this dumb crap is just
broken when cross-compiling to mingw.
player: show AV-desync message in all framedrop modes

This was shown only if decoder-framedropping was enabled, and only if at
least 50 frames were dropped by it. Since drop_frame_cnt used to mean
"number of late frames", this code made sense, but this is not the case
anymore: drop_frame_cnt can be even 0, all while video gets hopelessly
behind audio.

One problem with this is that short desync spikes (which usually can
probably dealt with) will also cause this message to be shown. If it
gets triggered too often, the code will need to be adjusted.
player: update meaning of drop_frame_cnt

Rename the variable, update comments, and update the documentation of
the property which returns its value.
build: remove bundle support from waf

Use TOOLS/osxbundle.py instead. It's just better and less hacky.
manpage: ipc: fix command name for observe_property
ipc: verify resume/suspend commands

Calling mpv_resume() too often is considered an API usage violation,
and will trigger an internal assertion somewhere.
ipc: add a command to retrieve API version
ipc: make it possible to receive log messages

The receiving part was implemented, but since no messages are enabled
by default, it couldn't be used.