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.