vaapi: try dealing with Intel's braindamaged shit drivers

So talking to a certain Intel dev, it sounded like modern VA-API drivers
are reasonable thread-safe. But apparently that is not the case. Not at
all. So add approximate locking around all vaapi API calls.

The problem appeared once we moved decoding and display to different
threads. That means the "vaapi-copy" mode was unaffected, but decoding
with vo_vaapi or vo_opengl lead to random crashes.

Untested on real Intel hardware. With the vdpau emulation, it seems to
work fine - but actually it worked fine even before this commit, because
vdpau was written and designed not by morons, but competent people
(vdpau is guaranteed to be fully thread-safe).

There is some probability that this commit doesn't fix things entirely.
One problem is that locking might not be complete. For one, libavcodec
_also_ accesses vaapi, so we have to rely on our own guesses how and
when lavc uses vaapi (since we disable multithreading when doing hw
decoding, our guess should be relatively good, but it's still a lavc
implementation detail). One other reason that this commit might not
help is Intel's amazing potential to fuckup anything that is good and
holy.
audio: limit on low (and not high) buffer size

The original intention was probably to avoid unnecessarily high numbers
of wakeups. Change it to wait at most 25% of buffer time instead of 75%
until refilling. Might help with the dsound problems in issue #1024, but
I don't know if success is guaranteed.
win32: emulate some ANSI terminal escape codes

We already redirect all terminal output through our own wrappers (for
the sake of UTF-8), so we might as well use it to handle ANSI escape
codes.

This also changes behavior on UNIX: we don't retrieve some escape codes
per terminfo anymore, and just hardcode them. Every terminal should
understand them.

The advantage is that we can pretend to have a real terminal in the
normal player code, and Windows atrocities are locked away in glue
code.
terminal-win: remove nonsensical code

Something about a non-working MinGW thing? Really, I don't care. It
also prevents using the console API properly.
terminal: some cleanups

In particular, remove all the stupid debug printfs from the win code.
terminal-win: read input from a thread

Surprisingly, WaitFor* works on console handles. We can simply run the
code for reading the console in a thread, and don't have to worry about
crazy win32 crap in the rest of the player's input code anymore.

This also fixes the issue that you couldn't unpause the player from the
terminal, because the player would stop polling for input.
terminal-unix: new input handling code

This is independent of terminfo/termcap, and supports more keys.
Originally, the goal was just extending the set of supported key
sequences, but since the terminfo stuff actually makes this much harder,
and since it's a big blob of bloated legacy crap, just drop it. Instead,
use hardcoded tables.

It's pretty easy to get on the same level as the old code (with fewer
LOC), and we avoid additional error situations, such as mallocs which
could fail (the old code just ignores malloc failures). We also try to
support some xterm escape sequences, which are in relatively widespread
use. (I'm not sure about the urxvt ones.)

Trying to deal with xterm shift/ctrl/alt modifiers is probably a bit
overcomplicated, and only deals with prefixes - xterm randomly uses
prefix sequences for some keys, and suffixes for others (what the heck).

Additionally, try to drop unknown escape codes. This basically relies
on a trick: in almost 100% of all situations, a read() call will
actually return complete sequences (possibly because of pipe semantics
and atomic writes from the terminal emulator?), so it's easy to drop
unknown sequences. This prevents that they trigger random key bindings
as the code interprets the part after ESC as normal keys.

This also drops the use of terminfo for sending smkx/rmkx. It seems
even vt100 (to which virtually everything non-legacy is reasonably
compatible with) supports the codes we hardcode, so it should be fine.

This commit actually changes only the code if terminfo/termcap are not
found. The next commit will make this code default.
build: disable terminfo and termcap code by default

If nobody complains soon enough, I will remove the code completely.
osc: revert disabling use_suspend

It was an unintended/accidental change.