cocoa: decouple events from application somewhat
cocoa: sync inputContext inside EventsResponder
cocoa: move set_input_context to macosx_events
cocoa: move handleFilesArray: to macosx_events
build: cocoa-application config target

I had to put it after video options because it depends on cocoa;
is there anywhere better to put it rather than making a new group?
cocoa: macosx_application needs cocoa-application
cocoa: fix build by using the correct HAVE_* macro

This builds but both the libmpv example and the cplayer block infinitely when
building libmpv. That's because we wait inifinitely in `dispatch_sync` as
there's no event loop in the main thread that allows for libdispatch to work..

Whiel we are at it, we should probably investigate how to use mp_dispatch
instead since it is a little lower level and could give us higher control in
building and event loop.
build: expose waf variants to the user

This allows the user to execute multiple configuration and build steps. It
can be used for several scenarios where you need different compiler flags.
build: allow to disable building the cplayer
wayland: changes for nested compositors

Adds necessary checks for nested compositors which only have limited
interfaces. Might also be useful for other minimal compositors.
wayland: remove redundant line
audio: fix inverted condition

Recent regression. Could perhaps make gapless audio fail to work
correctly.
client API: trigger MPV_EVENT_VIDEO_RECONFIG on vf recreation

Until now, it was done only on VO reconfig, but this easily can miss
some events, in case the VO output format doesn't change.
demux: make track switching asynchronous

Because why not.

This can lead to reordering of operations between seeking and track
switching (happens when the demuxer wakes up after seek and track
switching operations were queued). Do the track switching strictly
before seeks if there is a chance of reordering, which guarantees that
the seek position will always start with key frames. The reverse
(seeking, then switching) does not really have any advantages.

(Not sure if the player relies on this behavior.)
win32: never call GetClientRect(0, ...)

Sometimes GetClientRect() appeared to fail during init, and since we
don't check GetClientRect() calls (because they're on our own window,
and logically can never fail), bogus resizes were triggered. This could
cause vo_direct3d to fail initialization.

The reason was that w32->window was set to 0 during early window
initialization: CreateWindow*() can send messages to the new window,
even though it hasn't returned yet. This means w32->window is not yet
set to our window handle, and functions in WndProc may accidentally pass
hwnd=0 to win32 API functions.

Fix it by initializing w32->window on opportunity. This also means we
always strictly expect that the WndProc is used with our own window
only.
vo_direct3d: allow resizing before video init

This can just happen in the time between VO creation, and the first call
to vo_reconfig. It seems the recent threading changes exposed this bug.

Fixes #986.
stream_dvb: fix channels.conf preference order

channels.conf was never used (even though its config path was resolved).

Also remove the non-sense with the access() call.

Fixes #987 (untested).
stream_dvb: restore --dvbin-file option

Got lost some time ago. Although I'm not sure if it actually does
anything on MPlayer (it exists there, but might broken, not sure).

Fixes #988 (untested).
old-build: HAVE_COCOA_APPLICATION must be set

Also fix a typo in the Makefile manpage rule.
gitignore: fix manpage entries