demux_lavf: blacklist "tty" libavformat demuxer

This is completely useless, and in this particular case, it broke the
fallback for MLP2 subtitles (stored as .txt files) to demux_subreader.
(Yes, libavformat should be fixed to handle this, but for now this will
_always_ break playback of subtitle files stored in .txt.)

You can still force this demuxer, but by default we will just pretend
that the "tty" demuxer does not exist.
version.sh: integrate the release tag in output

This is basically reconstructed from 46b218c. Since we now have proper
release tags, we want this again.

Add --tags to the git describe call, because the github release system
creates light-weight tags only, and we're too lazy to create annitated
tags (or is that bad practice?).

Add --long, so that the git commit hash is part of the output even if
the tag matches.
version.sh: add --print option, which prints version to stdout

Might be helpful when creating a tarball.
core: make sure hw decoding works when playing multiple files

The hw decoding context was set only for the first file (when the VO was
initialized), instead of every file.
vo: unref waiting image before destroying VO driver

This is in theory more correct with respect to hardware decoding. With
hardware decoding, the VOs play the role of the video surface allocator,
and nothing is allowed to reference surfaces past the VO lifetime. But
in theory waiting_mpi could be a reference to a HW video surface, so it
should be relased before the VO is uninitialized.
x11_common: get hack for Motif Window Manager out of the way

Disable the hack by default, because it's interfering with some more
modern WMs. MWM (Motif Window Manager) is probably pretty dead, but
we still allow enabling the old hack with "--fstype=mwm_hack".

See github issue #179.
video: redo hw decoding initialization, add --hwdec=auto

Change how the HW decoding stuff is organized, the way it's initialized
in particular. Instead of duplicating the list of supported codecs for
hwaccel decoders, add a probe function which allows each decoder to
report whether it supports a given codec.

Add an "auto" choice to the --hwdec option, which automatically enables
hardware decoding if libavcodec and/or the VO supports it.

What mpv prints on the terminal changes a bit. Now it will just print
a single line whether hw decoding is used or not (and nothing at all if
no hw decoding at all was requested). The pretty violent fallback from
hw decoding to software decoding is still quite verbose and evil-looking
though.
sub: support straight alpha additionally to premultiplied alpha

This is for VAAPI support. VAAPI does not support premultiplied alpha
for OSD. (Normally, we prefer premultiplied, because it has better
behavior on scaling.)

I'm not sure whether blending in the ASS->RGBA part is correct and I
didn't test it extensively.
img_convert: add function to scale RGBA OSD images
video: add vaapi decode and output support

This is based on the MPlayer VA API patches. To be exact it's based on
a very stripped down version of commit f1ad459a263f8537f6c from
git://gitorious.org/vaapi/mplayer.git.

This doesn't contain useless things like benchmarking hacks and the
demo code for GLX interop. Also, unlike in the original patch, decoding
and video output are split into separate source files (the separation
between decoding and display also makes pixel format hacks unnecessary).

On the other hand, some features not present in the original patch were
added, like screenshot support.

VA API is rather bad for actual video output. Dealing with older libva
versions or the completely broken vdpau backend doesn't help. OSD is
low quality and should be rather slow. In some cases, only either OSD
or subtitles can be shown at the same time (because OSD is drawn first,
OSD is prefered).

Also, libva can't decide whether it accepts straight or premultiplied
alpha for OSD sub-pictures: the vdpau backend seems to assume
premultiplied, while a native vaapi driver uses straight. So I picked
straight alpha. It doesn't matter much, because the blending code for
straight alpha I added to img_convert.c is probably buggy, and ASS
subtitles might be blended incorrectly.

Really good video output with VA API would probably use OpenGL and the
GL interop features, but at this point you might just use vo_opengl.
(Patches for making HW decoding with vo_opengl have a chance of being
accepted.)

Despite these issues, decoding seems to work ok. I still got tearing
on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also
tested with the vdpau vaapi wrapper on a nvidia system; however this
was rather broken. (Fortunately, there is no reason to use mpv's VAAPI
support over native VDPAU.)
vo: fix build with #ifdef -> #if

Whoever had the idea of introducing mixed conventions for these
preprocessor symbols should be shot.
configure: fix typo
manpage: actually document --hwdec=auto
Revert "sub: support straight alpha additionally to premultiplied alpha"

This reverts commit 689a25003fc8098e5fdfbb2faefc0e18365d3acb, with some
adjustments to code that was added after that commit.

I just messed up big time. We don't need this, and in fact the commit
confused straight and premultiplied alpha at one point (just a simple
inverted condition due to an oversight), which is why it looked like
it was working.

In commit 2827295 I wrote:

   Also, libva can't decide whether it accepts straight or premultiplied
   alpha for OSD sub-pictures [...]

That was just me messing up and being severely confused by my own bugs.
VA API  uses premultiplied alpha, which by the way is nice and
thoughtful of the VA API devs.

Well, this was stupid. But in the end, I'm glad that I could actually
reduce codesize by a good amount again.
stream_bluray: fix bd:// url segfault introduced by commit bc1d61
demux_subreader: report what subtitle format has been found
demux: move demux_mf before demux_subreader

demux_subreader is quite aggressive, and sometimes detects random
strings in EXIF as subtitle text.
mpvcore/options: Update default user agent string

Uh… about time, I guess?
input: make input queue thread safe

If pthreads are enabled the input queue accesses are regulated by acquiring
a mutex. This is useful for platforms like OS X, where the events are created
in the cocoa thread and added to the queue to then be dequeued in the playloop
thread.
macosx: remove platform specific input queue

Since last commit the input queue in the core is thread safe, so there is no
need for all this platform specific stuff anymore.