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.
cocoa_common: add precise scrolling support

This adds precise scrolling support. I ran some tests and it seems a little
bit smoother and well.. precise. The defaults are rebindable using: AXIS_UP,
AXIS_DOWN, AXIS_LEFT and AXIS_RIGHT.
input.conf: bind AXIS_(LEFT|RIGHT) to seek 5

Binding them to volume was a bad default, so change it.
changes.rst: document some OSX and windows changes
vaapi: fix typo
x11: fix --ontop

Apply it after mapping.
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.