They can only be read safely under the Big Structure Lock in
src/misc/objects.c, so it makes no sense for them to be public.

By the way, making i_children volatile wouldn't magically solve
thread-safety issues. The only correct use of volatile is in dealing
with asynchronous changes _within_ the same thread, such as signal
handling.

P.S.: I wish modules were not objects, and I wonder why they are
(they don't don't use threads, nor plugins, nor variables)

This reverts commit c85f8681.

This reverts commit e5b3d194.

This reverts commit 68bcb6a4.

As pointed by courmisch, this is crashy.

Conflicts:

	src/vlc.c

Note: I don't think we did yet match the old behaviour, if we hit ctrl-c while in libvlc_new(), vlc isn't killed properly.

Signed-off-by: Pierre d'Herbemont <pdherbemont@videolan.org>

This reverts commit 3d7eabaf.
Signed-off-by: Pierre d'Herbemont <pdherbemont@videolan.org>

...if the destructor destroys them properly.

We need to do stuff BEFORE the playlist is destroyed

This will postpone a due abort or turn a crash into an abort.
Objects must not have children when they are destroyed per the current
design, though this seems to be a questionable choice.