Frontend plugin system too tightly coupled to wicket hierarchy

During the CMS workshop we tried to implement a tabbed GUI and immediately ran
into trouble with plugin creation and update notification.

1> Plugin creation:
Currently the plugin creation system assumes that the plugin hierarchy is 'clean',
plugins are added as direct children to plugins, there are no intermediate components
that aren't plugins.

However a wicket TabbedPanel needs just that, it needs an intermediate 'Tab' component.

During the cms workshop by this was solved by overriding the addChildren(PluginConfig)
method in TabsPlugin.

This is probably the best way to do it: Plugins can (should?) decide on how to add
their configured children.

2> Plugin update notification:
Currently the plugin update notification system assumes that all plugins are
reachable by following child relations in the wicket component hierarchy.

Again things are different with a wicket TabbedPanel as it swaps it's tabs (with the plugins)
in and out, it only holds the selected tab as child.

During the cms workshop by this was solved by adding the IConsumer interface.

In general using a listener is probably better for keeping track of all the Plugins
than depending on the wicket component hierarchy. A TabbedPanel is probably not
the only plugin container that has it's own ideas about managing it's children.