demux_playlist: don't ignore last line in m3u

If EOF is reached after reading a line, the EOF flag is set. This was a
problem for the m3u code, which checked for EOF _after_ reading a line,
which will discard the last line read.

Also fix a typo in an unrelated part of the file.
ao/wasapi: get rid of WAVEFMT union

It only confused the issue. Replace it's functionality with
waveformat_copy function where needed.
ao/wasapi: make sure that < 16-bit pcm never happens

it just sucks. noone should have to listen to that.
ao/format: add af_fmt_is_float
ao/wasapi: don't assume 32-bits == float

This was based on old WAVEFORMATEX restrictions
http://msdn.microsoft.com/en-us/library/windows/hardware/ff538799%28v=vs.85%29.aspx

With the new WAVEFORMATEXTENSIBLE, this is no longer a problem. and we
can have s32 or float32 so we need to actually check / set these correctly.

fixes #1287
ao/wasapi: show actual waveformat tried

also remove bogus ao_format
ao/wasapi: fix set_ao_format

Before it used whatever was in ao->format and changed the bits even
though this might have nothing to do with the actual WAVEFORMAT
negotiated with WASAPI.

For example, if the initial ao->format was a float and we had set the
WAVEFORMAT to s24, this would create a non-existent float24 format.
Worse, it might put an u16 into ao->format when WAVEFORMAT described s16.
WASAPI doesn't support unsigned at all as far as I can tell.
ao/wasapi: make set_ao_format EX/EXTENSIBLE agnostic

There is no guarantee that closestMatch returned by IsFormatSupported
is actually a WAVEFORMATEXTENSIBLE.

http://msdn.microsoft.com/en-us/library/windows/desktop/dd370876%28v=vs.85%29.aspx

We should therefore not blindly treat it as such.
vd_lavc: don't crash if codec could not be opened

Fixes #1307.
vo_opengl: remove redundant GL state initialization

All of these are already the defaults.

One exception is glDepthMask(), which is enabled by default. But if the
framebuffer has no depth buffer anyway, it shouldn't make a difference.
audio: allow more than 20 channel map entries

This could trigger an assertion when using ao_alsa or ao_coreaudio. The
code was simply assuming the number of channel maps was bounded
statically (which was true at first in both AOs).

Fix by using dynamic memory allocation. It needs to be explicitly
enabled by the AOs by setting a temp context, because otherwise the
memory couldn't be freed. (Or at least this seems to be the most elegant
solution.)

Fixes #1306.
options: simplify channel map validation

The min=-1 case was never used, and the channel map must always be valid
(or in some cases, invalid but empty).
options: fix swapped deprecated/replacement in warning

This was relevant for --af and --vo (both use this option type, and have
deprecated aliases).
options: fix channel map options sometimes failing

Channel amp otpions were not copied correctly: it copied the size of a
pointer to struct chmap, not the struct itself. Since mp_chmap is
currently 9 bytes, this meant the last channel entry was not copied
correctly on 64 bit systems, leading to very strange failures. It could
be triggered especially when using the client API, because the client
API always copies options on access (mpv command line options tend to
work directly on options).
ao_coreaudio: initialize fetched properties to zeros

Should hopefully fix #1249 and #1279
cocoa: allow to black out other display when going fs

fixes #1302
audio: fix one of the previous commits

Fixes commit 52c51149. It broke multichannel (or possibly everything)
for ao_alsa, ao_oss, ao_sndio.
cocoa: fix opening reference URLs (.file/id=)

Fixes #1202

/cc @mpv-player/stable
cocoa: split mkv/webm for imported UTI in plist
DOCS/client-api-changes: mark release 0.7.0