player: wait for vout when releasing on Darwin systems

EDIT: removed. /!\ Disclamer: this is a work-in-progress draft, currently not really tested, not cleaned-up, and probably not polished enough. I'd like to have the system-specific part removed from the vlc_player code and moved to a module instead, but there is no entrypoint for that currently. It could be done with an abstraction over windowing platforms that can be created before the vout thread / the window but I'm not ready yet to design such work, and it seems that it would have a limited usage since most other windowing platform implementation are not leaking abstraction details on the libvlc application side.

It needs a lot of tests and reviews before thinking about merging.

---

The video output code in VLC is locking in the following order:

1/ During initialization

• vout window
  • main thread lock at init
• vout display
  • main thread lock at init

2/ During runtime

• main thread event
  • vout window
    • vout display

There is a deadlock that could happen while the vout display is initializing and the vout window reports an event to the display. This was tackled by the reportEvent handling function in the VLCVideoUIView.m module.

But the locking order is different again in the user application. Everything is asynchronous for the user, so locking in the video output is not an issue most of the time, except during the release of media players while the input is still running where the following lock order could happen:

User application:

• main thread
• libvlc_media_player
• vlc_player
• vlc_player destructor (joining here)

vlc_player_destructor:

• input thread / input resource
• video output
• vout window
• main thread

So another lock inversion happens here. To avoid it, this patch change the following for the user application side:

User application:

• main thread
• libvlc_media_player
• vlc_player
• main thread loop restricted to VLC events (waiting for destructor thread to destroy the vout, leave the loop and almost return)
• vlc_player destructor (joining here)

So window and display will be able to fullfill their initialization and then be closed correctly.