tv: unqueue buffers correctly (maybe, maybe not)

I clue no idea what I'm doing, but at least it doesn't hang anymore when
closing a tv:// stream using a v4l2 loopback device.
tv: remove duplicated crap

The logging functions already add a prefix. Original MPlayer devs must
have liked code duplication a lot.
stream: remove duplicate message
stream: fix --stream-dump dropping the file header

stream_rar.c peeks the first few bytes when trying to open, which means
that opening any stream reads at least 2KB of data (internal buffer
size) on opening. This broke --stream-dump, which saved only the data
following this initial buffer.

Hack it around by writing the current buffer to the capture file too,
and move stream_capture_write() above stream_set_capture_file() for this
purpose.

Cleaner solutions might include: handling the terrible rar thing
differently, or using the "proper" stream API for dumping. (The latter
is not done, because --stream-dump shares code with the --stream-capture
misfeature.)

Fixes #1215.
build: enable cdda:// by default again

Apparently people want this. (???)

See #1214.
lua: fix some more lua_tostring() mistakes

Why can't it just raise an error?
tv: reduce waiting loop from 10ms to 1ms

I can't believe how shitty this (MPlayer-derived) code is. Maybe it
should be fixed or be replaced with using libavdevice, but that doesn't
seem worth the effort.

Anyway, for now reduce the time it's blocking to wait for new frames
from 10ms to 1ms, because 10ms might be a bit too tight: it could
deliver the frame up to 10ms late - now it's only up to 1ms. (And yes,
it does that instead of using condition variables. It also abuses
volatile variables as atomics. It's hilarious.)
tv: remove some differences between immediate/normal mode

The immediate mode (which is the default) uses a tiny ringbuffer and
doesn't grab timestamps. This leads to quite bad behavior due to the
fact that there's an additional buffer between playloop and TV code (the
demuxer thread, which doesn't exist in MPlayer).

Always grab the timestamps and use a decently-sized buffer. I still have
no clue what I'm doing, and hacked it until it appeared to work. Report
regressions if you experience any.
manpage: use the proper environment variable for CSIDL_APPDATA
video: initial dxva2 support

Shamelessly stolen from ffmpeg. It probably doesn't work - you can debug
it yourself.
Drop libquvi support

No development activity (or even any sign of life) for almost a year.

A replacement based on youtube-dl will probably be provided before the
next mpv release. Ask on the IRC channel if you want to test.

Simplify the Lua check too: libquvi linking against a different Lua
version than mpv was a frequent issue, but with libquvi gone, no
direct dependency uses Lua, and such a clash is rather unlikely.
build: fix Lua detection

We need to manually define the flag since we are using a separate identifier
for each of the Lua checks. This was done before 9b45b48 by the composed check
with a define_key (see waftools/checks/generic.py).

The pkg-config check was the only one to not redefine a define key because Waf
already does that automatically when we call the generated function with the
same identifier as the generator function. Now if they are called with two
different arguments we will get two different definitions.

Fixes #1218
lua: subprocess: don't distinguish pipe errors/EOF

What was the purpose of that? Probably none.

Also simplify another thing: if we get the cancel signal through FD,
there's no reason to check it separately.
lua: parse_json(): fix inverted condition for trail argument

It accidentally had the opposite meaning.
osdep: add helper for creating a sane pipe()

Or in other words, a pipe that has the CLOEXEC flag set. Needed since
Linux' pipe2() is not in POSIX yet.
lua: subprocess: tunnel stderr through mp_log

Pretty much a fringe-feature, but also it's awkward if something appears
on the terminal with no indication for the source.

This is made quite awkward by the fact that stderr and stdout could be
closed at different times, and that poll() doesn't accept "holes" in its
FD list. Invalid (.e.g negative) FDs just make it return immediately, as
required by the standard. So sparse_poll() takes care of the messy
details.
lua: subprocess: fix dumb
dxva2: use optimized memcpy

At least on my machine, reading back the frame with system memcpy is
slower than just using software rendering. Use the optimized gpu_memcpy
from LAV to speed things up.
video: clarify what IMFMT_DXVA2 is
vo_direct3d: support nv12/nv21 directly