We have enough static locks in libvlc, I think: the
configuration R/W lock, the module bank mutex, the system-specific
initialization mutex, the message subscription R/W lock, the sets
of mutexes for initializations of specific libraries, the LibVLC
thread variable mutex, the configuration file mutex, the PRNG mutex,
the object pipe mutex, the object name mutex, the dialog provider
mutex, the interface module registration mutex, the OSD mutex, the
VLM mutex, the HTTP hosts mutex and the OSD mutex...

In other words, the message callbacks are now shared across all LibVLC
instances. That is a requirement to enable:
 - LibVLC applications to catch messages during LibVLC init/deinit,
 - emitting log messages when no VLC object point is available.

That makes no difference for VLC interfaces, since there is only one
LibVLC instances in a VLC process.

macosx: work-around CoreAnimation limitations on 10.6, which prevented the correct display of some ui elements

macosx: show the playlist size as a badge in the sidebar and fixed an appearance issue of the sidebar

macosx: converted interface builder files from nib to the more modern xib file format, which smaller and more suitable for git

Modified-by and Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

There is no potentially cancellation-unsafe code here (unlike Qt4),
since msg_Free() is safe and vlc_mutex_*() of course too.

Contrary to C, C++ compilers don't promote larger constants up to
unsigned long long when needed.