if allowed, launch a timeout keep-a-live thread

Close #1998.
(cherry picked from commit fd3426910f6ffa1db76659974ff54ba24363217a)
(cherry picked from commit 56c38ae8d2f4a31aa2145997a7bb603a50a11811)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 1d4f7191)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Few people will likely care about the AR of their subs.

At worst it will use a lot of CPU but this will allow to detect buggy
access/access_demux module.

Interfaces are updated every 250 millisecond.
Statistiques are updated every second.

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.