Close #1122
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

This reduces the amount of memory copied when creating/deleting a
variable on an object. We now use a table of pointers instead of table
of variable_t.

This also simplifies callback handling a bit as the variable_t cannot
move anymore while we wait. Earlier another thread could add or remove
another variable on the same object, thus changing the variable table.

With this change, we could also store non-serialized data (i.e.
non-movable with memcpy/memmove) directly inside variable_t.

Only default to rc.lua if module loading wasn't forced. This still isn't perfect. (And there seems to be an issue in module_need(), wasn't -I intf1,intf2 supposed to first try loading intf1 and fallback to intf2 if intf1 couldn't load? For example -I rc,qt4 should load rc and not qt4, which is the case in 0.8.6 but doesn't seem to be the case in 1.0.0 ... looks like this is due to bb0d7527 removing i_shortcut_bonus)

We use the same pattern as the variable callback lock: one mutex,
one condition variable and N boolean flags instead of N mutexes.
This is a bit slower but it shouldn't leak OS handles anymore.

First one is about starting to inherit from the parent. Shouldn't hurt much.
Second one is about looking to inherit from the right variable. hurt more.

Make the dialogs that requires no user action and that will be normally handled via regular error code path optionals.

Still, there is no context with those dialogs, and we don't know to what output they belongs, ideally we should have a proper API that makes the client a proxy for those user actions.

If the lua rc submodule gets autoselected because it has the higher priority, we need to correctly use it.

Only enable when X window support is wanted.
Feel free to adjust.

Close #2763

This may hopefully spare us some conflicts with VLCKit/libvlc users.

This is meant to fix the *printf format strings.
This is compatible with mingw 4.2.1 and 4.3.0
I haven't find a better place where to put this code...
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

We don't have the renderer for it, so far.

Close #3213

Close #2866