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.