gl_common: add some sort of locking API

Some OpenGL implementations on some platforms require that a context
is current only on one thread. For this reason, mpgl_lock() and
mpgl_unlock() take care of this as well for convenience.

Each backend that needs thread safety should provide it's own locking strategy
inside of `set_current`.
vo_opengl: lock OpenGL context

To simplify things, we just assume that all OpenGL calls as well as
all calls into gl_video must be locked. Currently, also assume that
anything GUI related must be locked as well (stuff like VOCTRL_BORDER).

In its current state, this commit does nothing, but it will allow us to
move the Cocoa GUI out of the playloop, as well as possibly implementing
better framedropping.
add a way to resize window contents without VO resize

gl_video_resize_redraw() simply resizes and redraws (but without
invoking swapGlBuffers()). The VO is not involved in any way, so this
can simply be called from inside the mpgl lock from any thread.

Requires a minor refactor of the GL OSD code in order to redraw without
an OSD object.
OSX: use native Cocoa's event loop

Schedule mpv's playloop as a high frequency timer inside the main Cocoa event
loop. This has the benefit to allow accessing menus as well as resizing the
window without the playback being blocked and allows to remove countless hacks
from the code that involved manually pumping the event loop as well simulating
manually some of the Cocoa default behaviours.

A huge improvement consists in removing NSApplicationLoad. This is a C function
defined in the Cocoa header and implements a minimal OSX application under ther
hood so that you can use the Cocoa GUI toolkit from C/C++ without having to
respect the Cocoa standards in terms of application initialization. This was
bad because the behaviour implemented by NSApplicationLoad was hard to customize
and had several gotchas especially in the menu department.

mpv was changed to be just a nib-less application. All the Cocoa part is still
generated in code but the event handling is now not dissimilar to what is
present in a stock Mac application.

As a part of reviewing the initialization process, I also removed all of
`osdep/macosx_finder_args`. The useful parts of the code were moved to
`osdep/macosx_appication` which has the broaded responsibility of managing the
full lifecycle of the Cocoa application. By consequence the
`--enable-macosx-finder` configure switch was killed as well, as this feature
is always enabled.

Another change the users will notice is that when using a bundle the `--quiet`
option will be inserted much earlier in the initializaion process. This results
in mpv not spamming mpv.log anymore with all the initialization outputs.
OSX: run native event loop in a separate thread

This commit is a followup on the previous one and uses a solution I like more
since it totally decouples the Cocoa code from mpv's core and tries to emulate
a generic Cocoa application's lifecycle as much as possible without fighting
the framework.

mpv's main is executed in a pthread while the main thread runs the native cocoa
event loop.

All of the thread safety is mainly accomplished with additional logic in
cocoa_common as to not increase complexity on the crossplatform parts of the
code.
macosx_application: add menu item for hide operation

Fixes #35
cocoa_common: add native OSX fullscreen support

This adds Mission Control fullscreen functionality to mpv. Since this doesn't
play well with many of mpv's features disable it by default. Users can activate
this feature by using `--native-fs` when starting mpv.

Fixes #34