This reverts commit 7cc631ac.

freetype.c and quartztext.c contain a lot of common code, that should
be factorized.

So there are no deadlocks if multiple threads are waiting on the same
object (although that's not a very brilliant idea).

Get rid of unsafe PulseEvent().
Fix recursive mutex implementation (hopefully).
Use critical section (fast non-shared/intra-process mutexes)
 rather than mutex handle (slow shared/inter-process mutexes) [1].
Do not rely on unspecified locking when SignalObjectAndWait is alerted.
Real vlc_cond_broadcast() support (hopefully).

[1] should also merge the WinCE support with WinNT.

The overhead of calling a function is rather tiny compared to the
overhead of doing the system call these typically involve.

Also refs #1392

Seems like this is needed for proper vlc_object_kill() (if more than
one thread waits on a given object).

Threads can be cancelled and are not killed by default.

Windows API expect a timeout in millisecond.
SignaObjectAndWait should properly work with a 0 timeout, so try it.
(avoid an invalid lock and an uninitialized return value).

Copy palette to fmt_out.
No you cannot blindly copy between VLC and FFmpeg structures...

SwScaler uses a really ugly hack to transmit the palette.

Pointed-out-by: Laurent Aimar

Variables callback can be (and usually are) invoked from other threads.
They cannot access the object without locking, and must be unregistered
before the object is destroyed (var_DelCallback() -> free(p_sys)).

(Currently, <1ms on Linux, and <0 on others)

Thanks Courmisch for pointing it.

This fixes a few "deadlocks" with input waiting for playlist, while
playlist is waiting for input event.

Also do not needlessly lock after unregistering the callbacks. We have
to assume that when var_DelCallback returns, any pending callback
invocation has be completed. Otherwise, we would any crash when Close()
releases the mutex, destroys it, and the callback then tries to acquire
the mutex.