demux: minor cleanups
Audit and replace all ctype.h uses

Something like "char *s = ...; isdigit(s[0]);" triggers undefined
behavior, because char can be signed, and thus s[0] can be a negative
value. The is*() functions require unsigned char _or_ EOF. EOF is a
special value outside of unsigned char range, thus the argument to the
is*() functions can't be a char.

This undefined behavior can actually trigger crashes if the
implementation of these functions e.g. uses lookup tables, which are
then indexed with out-of-range values.

Replace all <ctype.h> uses with our own custom mp_is*() functions added
with misc/ctype.h. As a bonus, these functions are locale-independent.
(Although currently, we _require_ C locale for other reasons.)
demux_mkv: minor improvement to overflow check

CC: @mpv-player/stable
demux: drop AVI special code

I'm pretty sure libavformat does this automatically, and we don't have
other demuxers where this could happen.

Still, slightly "risky" - so let's see.
command: change cache perentage to float, add cache-free and cache-used
command: cache can actually have full-size 0

Then it's simply empty.
command: remove some code duplication in cache properties

This also means that the printed size is always rounded to KBs, because
the cache properties are returned in KB. I think this doesn't matter
much. But if it does, the cache properties should probably changed to
return bytes in the first place.
x11: clear window only on initial map

Apparently clearing on every map can cause problems with vdpau when
switching virtual desktops and such. This was observed with at least
XMonad and nvidia-340.17. It's not observed on some other setups without
XMonad.

It's not clear why this happens. Normally, the window background is not
saved, so clearing should have no additional affect. It's a complete
mystery. Possible, the use of legacy X drawing commands (used to clear
the window) interferes with vdpau operation in non-trivial ways.

Work this around by clearing on initial map only. This probably only
hides the underlying issue, but good enough.

Closes #897.

CC: @mpv-player/stable
cache: clear DVD timestamps

When resizing the cache, the buffer for the DVD timestamps is
initialized with 0. This causes the player to always return playback
position 0 with any file format (not just DVD), and also makes all
relative seeks relative to position 0. Fix this by clearing the
timestamps explicitly.

Closes #899.

CC: @mpv-player/stable
ao_coreaudio: move spdif code to a new AO

The mplayer1/2/mpv CoreAudio audio output historically contained both usage
of AUHAL APIs (these go through the CoreAudio audio server) and the Device
based APIs (used only for output of compressed formats in exclusive mode).

The latter is a very unwieldy and low level API and pretty much forces us to
write a lot of code for little workr. Also with the widespread of HDMI, the
actual need for outputting compressed audio directly to the device is getting
lower (it was very useful with S/PDIF for bandwidth constraints not allowing
a number if channels transmitted in LPCM).

Considering how invasive it is (uses hog/exclusive mode), the new AO
(`ao_coreaudio_device`) is not going to be autoprobed but the user will have
to select it.
ao_coreaudio: remove useless call to print_asbd
ao_coreaudio: move device related functions to the new AO
ao_coreaudio: split control to helper functions
ao_coreaudio: fill asbd with an helper function
ao_coreaudio: rename init_lpcm -> init_audiounit
ao_coreaudio: remove useless comments
ao_coreaudio: use mpv's internal pull API
ao_coreaudio: move channel mapping away from utils

Channel mapping functions are only used in the AUHAL based coreaudio, so move
them there.
cache_file: use unicode on windows

This enables the MinGW Windows crap wrapper for fopen().
ao_coreaudio: report latency more correctly

Previous code was completly wrong. This still doesn't report the device
latency, but we report the buffer latency (as before the AO refactoring) and
the AudioUnit's latency (this is a new 'feature').

Apparently we can also report the device actual latency and we should also
calculate the actual sample rate of the audio device instead of using the
nominal sample rate, but I'll leave this for a later commit.