gl_common: add some sort of locking API, implement for X11

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.
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 crap.
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.

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.
cocoa_common: use libdispatch to synchronize uninit

setPresentationOptions is quite problematic and cause some sort of race
condition with the cocoa event loop during uninit
gl_common: remove pthread based locking

Each backend that needs thread safety should provide it's own (possibly
platform dependent)locking strategy inside of `set_current`.
cocoa_common: use non-recursive locks

Recursive locks were cool during development to troubleshoot deadlocks etc.
This not not needed anymore now that the code is stable.
osx: bundle: fix two bugs in the file opening code

There was a missing assignment of self.willStopOnOpenEvent which caused the
cocoa event loop to stop. Fixeing this exposed two other bugs:

  * The stop was called directly without posting a fake event (which could
    result in nothing happening until the user interacted with mpv's GUI
    causing Cocoa to post an event).
  * `cocoa_stop_runloop()` was not synchronous in it's fake event posting
    leading to race conditions.