vo_corevideo: fix regression in colormatrix handling

Regression since 18b6c01d92. That commit changed the colorspace handling to
always reinit the video output. Since the CVPixelBuffers are lazily created,
VOCTRL_SET_YUV_COLORSPACE was always called when the CVPixelBufferRef was NULL.

Since CoreVideo functions do not complain when called on NULL, no one noticed
that CVBufferSetAttachment, which stored the color matrix meta data was called
on NULL.
configure: fix help for macosx-bundle from autodetected to disabled

The help and configure result wrongly showed this feature was autodetected,
while it is infact disabled by default.
vo_corevideo: don't set colormatrix on direct rendering path

The current code uses GL_YCBCR_422_APPLE texture format. This allows to handle
transparently the conversion to RGB but always use BT.601 colormatrix [1].

Hopefully I can adapt gl_video to take CVPixelBuffers soon so that `vo=opengl`
can be used instead of `vo=corevideo` with `hwdec=vda`

 [1]: http://www.opengl.org/registry/specs/APPLE/ycbcr_422.txt
      http://www.opengl.org/registry/specs/APPLE/rgb_422.txt
vo_corevideo: convert to use reconfig instead of config
vo_corevideo: use dwidth/dheight for window dimensions

In the previous commit I wrongly used params->d_h/d_w which happened to work
by chance.
wayland/egl: rework resizing (again)

Moves a good chunk of the resizing code to wayland_common.c. This makes it
possible to share it with future video drivers.

It doesn't resizit it immediatly, it calcutlates the new position and size and
then shedules a resizing event. This removes the ugly callback and void pointer
from the wayland data structure.
wayland: remove shm listener for the backend

The obtained information from the shm listener isn't used by anything and is
also wrong now in wayland git master branch because of new shm formats which
need a different way of saving the supported formats.
wayland: shm based software rendering

A wayland output based on shared memory. This video output is useful for x11
free systems, because the current libGL in mesa provides GLX symbols. It is also
useful for embedded systems where the wayland backend for EGL is not
implemented like the raspberry pi.

At the moment only rgb formats are supported, because there is still no
compositor which supports planar formats like yuv420p. The most used compositor
at the moment, weston, supports only BGR0, BGRA and BGR16 (565).

The BGR16 format is the fastest to convert and render without any noticeable
differences to the BGR32 formats. For this reason the current (very basic)
auto-detection code will prefer the BGR16 format. Also the weston source code
indicates that the preferred format is BGR16 (RGB565).

There are 2 options:
    * default-format (yes|no)  Which uses the BGR32 format
    * alpha (yes|no)    For outputting images and videos with transparencies
audio: make internal audio format 0 an invalid format

Having to use -1 for that is generally quite annoying.

Audio formats are created from bitmasks, and it can't be excluded that
0 is not a valid format. Fix this by adjusting AF_FORMAT_I so that it
is never 0. Along with AF_FORMAT_F and the special formats, all valid
formats are covered and guaranteed to be non-0.

It's possible that this commit will cause some regressions, as the
check for invalid audio formats changes a bit.
audio: don't allow setting unknown formats from command line

af_str2fmt_short(), which is used by the command line option parser,
allowed passing a hex number. The user could set arbitrary integers as
internal audio formats, even formats which don't exist or make no sense.
This is not very useful, so get rid of it.
core: add a playlist demuxer

Modeled after the old playlist_parser.c, but actually new code, and it
works a bit differently.

Demuxers (and sometimes streams) are the component that should be used
to open files and to determine the file format. This was already done
for subtitles, but playlists still use a separate code path.
stream: fix url_options field, make protocols field not fixed length

The way the url_options field was handled was not entirely sane: it's
actually a flexible array member, so it points to garbage for streams
which do not initialize this member (it just points to the data right
after the struct, which is garbage in theory and practice). This was
not actually a problem, since the field is only used if priv_size is
set (due to how this stuff is used). But it doesn't allow setting
priv_size only, which might be useful in some cases.

Also, make the protocols array not a fixed size array. Most stream
implementations have only 1 protocol prefix, but stream_lavf.c has
over 10 (whitelists ffmpeg protocols). The high size of the fixed
size protocol array wastes space, and it is _still_ annoying to
add new prefixes to stream_lavf (have to bump the maximum length),
so make it arbitrary length.

The two changes (plus some more cosmetic changes) arte conflated into
one, because it was annoying going over all the stream implementations.
stream: don't drop buffer when creating the cache

This is really not needed. While we really can't take a loaded buffer
over to the cache, there's no reason why the cache couldn't read this
buffer normally.

On the other hand, this code could cause trouble when probing from a
stream before the cache has been enabled.
stream: change open code, add stream filter concept

Add a stream filter concept, in which streams can be opened on top of
an underlying "source" stream. Change the open code to make this
easier, and also to account for some mechanisms that will be needed
for this.

The following commit will add stream_rar, which contains such a stream
filter.
stream: add uncompressed rar support

Apparently, it is popular to store large files in uncompressed rar
archives. Extracting files is not practical, and some media players
suport playing directly from uncompressed rar (at least VLC and some
DirectShow components).

Storing or accessing files this way is completely idiotic, but it is
a common practice, and the ones subjected to this practice can't do
much to change this (at least that's what I assume/hope). Also, it's
a feature request, so we say yes.

This code is mostly taken from VLC (commit f6e7240 from their git tree).
We also copy the way this is done: opening a rar file by itself yields
a playlist, which contains URLs to the actual entries in the rar file.
Compressed entries are simply skipped.
gl_video: fix odd video sizes with PBOs

Odd video sizes if pixel formats with chroma subsampling and PBOs were
used, garbage was rendered. This was because the PBO path created
buffers with an unpadded size, and then tried to upload a padded
image to it. Fix it by explicitly setting the padded size. (As with
the non-PBO path, we rely that image allocations are somehow padded,
which is normally the case.)
wayland/shm: use opaque regions

Make use of opaque regions on non-alpha formats. This allows the compositor to
improve the drawing of the surface, because he can discard everything behind
the window when drawing.
wayland: don't create our own log context

This was more problematic than useful ([vo/wayland/wayland])
configure: move wayland-egl check

This makes it possible to build the shm backend when no EGL platform is
available.
configure: fix VDA autodetection based on FFmpeg support

The original condition was too weak, requiring only the header. The header is
installed is FFmpeg regardless of the presence of VDA on the system, so just
perform a check on the `ff_vda_create_decoder` function.