sub: fix accidental subtitle overlaps

The fix_overlaps_and_gaps() function in dec_sub.c fixes small gaps or
overlaps between subtitle events. However, sometimes it could happen
that the corrected subtitle events could overlap by 1ms due to bad
rounding, making libass shift subtitles to reduce collisions. (The
second subtitle will be shown above the previous one, even if both
subtitles are visible only for 1ms.)

sd_ass.c rounds the timestamps when converting to integers for unknown
reasons. I think it would work fine without that rounding, but since
I have no clue why it rounds, and since it could be needed to ensure
correct timestamps with ASS subtitles demuxed from Matroska, I'd rather
not touch it. So the solution is to use already rounded timestamps to
calculate the new subtitle duration in fix_overlaps_and_gaps().

See github issue #182.
input: fix build if HAVE_PTHREADS is undefined
vo_corevideo: add uyvy422 pixel format support

Looks like the vda_h264_dec in ffmpeg likes to output this format and it
inserted swscale to do pixfmt conversion to yuyv422.
video/decode: pass parameters directly to hwdec allocate_image callback

Instead of passing AVFrame. This also moves the mysterious logic about
the size of the allocated image to common code, instead of duplicating
it everywhere.
vd_lavc: fix comment, document hwdec video frame size trickiness

About this issue, it would be better if the surfaces could be allocated
with the real size, and the vdpau video mixer could be created with that
size as well. That would be a bit hard, because the real surface size
had to be communicated to vdpau. So I'm going with this solution. vaapi
seems to be fine with either surface size, so there's hopefully no
problem.
video/decode: change fix_image callback

This might make it slightly easier when trying to implement surface
read-back for hardware decoding.
vdpau: fix compilation on Libav

Libav's <libavcodec/vdpau.h> header uses some libavocdec symbols without
forward-declaring them and without including the headers declaring them.
FFmpeg's header for this is fine.
bstr: add UTF-8 validation and sanitation functions
sub: if charset detection fails, treat it as broken UTF-8

Broken UTF-8 in this context means we treat it as UTF-8, but we also
interpret broken UTF-8 sequences as Latin1.

Also, run our own UTF-8 check function before the charset detectors.
This prevents from ENCA's UTF-8 check possibly messing up (like
detecting 7-bit clean UTF-8 as ASCII, or other things). It also takes
care of UTF-8 detection if no charset detector (ENCA, libguess) is
compiled in, and it lets us deal better with cut-off UTF-8 sequences.
bstr: make UTF-8 check stricter

Don't accept overlong sequences. Don't accept codepoints past the
maximum unicode codepoint. Don't accept the UTF-16 surrogate codepoints.

I'm not sure if there are more codepoints that are defined to be
invalid, but we just want to make libavcodec happy, so this is enough.

(libavcodec's subtitle converter checks for valid UTF-8 and throws up
and dies if it's not - now we want to use bstr_sanitize_utf8_latin1() to
force valid UTF-8, so the strictness of our UTF-8 parser has to match at
least that of the libavcodec's check.)

I'm not sure whether the min test is actually 100% correct.

Note that libavcodec also treats BOM codepoints as invalid. This is
definitely a bug: the BOM is really just "zero-width non-breaking space"
redefined by Microsoft, but it is perfectly valid to appear in the
middle of a string. Official Unicode has merely deprecated the old
usage of the BOM codepoint, and didn't make it illegal. Besides, the
string could be from the start of a file, so even this check doesn't
make sense even with libavcodec's insane logic. We don't copy this bug.
sub: allow specifying a fallback codepage if input is not UTF-8

Normally, --subcp always forces conversion. This really always forces
conversion, even if the UTF-8 check on the input succeeds.

Extend the --subcp to allow codepages as fallback if UTF-8 doesn't
work. So, for example --subcp=utf8:cp1250 will use UTF-8 if the input
looks like UTF-8, and will fall back to use cp1250 if the UTF-8 check
fails.

I think this should actually be the default, but on the other hand,
this changes the semantics of the option, and a user would actually
expect --subcp to force conversion, rather than silently using UTF-8
if that happens to work.
sub: make --subcp=enca the default.
manpage: fix incorrect ao_alsa example, extend changes.rst

One example in ao.rst used the old syntax with mangled device names.
Fix it. Mention some shell related caveats. Explicitly mention the
change of device name syntax in changes.rst, because it seems to be
a common issue.
vdpau_old: add forgotten probe callback

Could make it crash if the VO didn't support vdpau decoding.
sub: don't print detected charset if it's UTF-8

Too noisy. This also fixes that iconv() was called if "utf8" was used
as codepage.
sd_lavc_conv: don't check AV_CODEC_PROP_TEXT_SUB flag

Not actually useful. This would break whenever a new text subtitle
format would be added, which requires a binary->text transformation.
(mov_text is one such format; disable it.) In general, we would have
to know which packet formats are binary, which we don't, so the only
reasonable way to handle this is a white list.
m_option: make defval const

There's really no reason why it shouldn't.
m_option: add missing copy callback for some option types

One reaosn for this is that this broke proper handling of .defval, since
m_option_copy did nothing for these option types.
vo_vdpau: allow setting colorkey

Formally, this sets the "background color" of the presentation queue.
But in practice, this color is also used as colorkey.

This commit doesn't change the VDPAU default yet.
vo_vdpau: use color close to black as default colorkey (instead of green)

The VDPAU default colorkey, although it seems to be driver specific, is
usually green. This is a pretty annoying color, and you usually see it
briefly (as flashes) if the VDPAU window resizes.

Change it to some shade of black. The new default color is close to what
MPlayer picks as colorkey (and apparently it worked well for them):

    VdpColor vdp_bg = {0.01, 0.02, 0.03, 0};

Since our OPT_COLOR can set 8 bit colors only, we use '#020507' instead,
which should be the same assuming 8 bit colors.

Obviously, you can't use black, because black is a way too common color,
and would make it too easy to observe the colorkey effect when e.g.
moving a terminal with black background over the video window.