Work-around window-on-top + fullscreen deadlock (refs #882)

Work-around window-on-top + fullscreen deadlock (refs #882)

FIXME FIXME FIXME FIXME: EXPLICIT HACK.
On the one hand, we cannot hold the lock while triggering a callback, as
it causes a deadlock with video-on-top handling. On the other hand, we
have to lock while triggering the callback to:
 1/ make sure video-on-top remains in sync with fullscreen (i.e.
    unlocking creates a race condition if fullscreen is switched on and
    off VERY FAST).
 2/ avoid possible corruption bugs if another thread gets the mutex and
    modifies our data in-between (though it does not seem like it could really
    do much harm in this particular case).

This is obviously contradictory. Correct solutions may include:
 - putting the fullscreen NAND video-on-top logic out of libvlc,
   back into the video output plugins (ugly code duplication...),
 - serializing fullscreen and video-on-top handling properly instead of
   using the fullscreen callback. That's got to be the correct one.