Don't rely on pluginconfig/plugincluster JCR node ordering but use an explicit property to order by, if even needed

The current CMS pluginconfig/plugincluster configurations use and rely on JCR node ordering (having parentNodeType.orderableChildren=true) for ensuring specific plugin(cluster)s are loaded in the right order.

Examples are the Perspective tabs, Browser perspective navigator dropdown, Admin perspective Control panel list of actions, etc., etc.

This however is problematic to maintain because:

• modules needing to 'insert' a plugin between existing plugins need to use orderBefore using delta XML, which is tricky and not always well understood
• the above also often can or will introduce an 'implicit' dependency on the bootstrap (and name) of such other plugins, which may come from another optional module, thereby not even getting the guarantee that the orderBefore will become effective
• orderable children in general is troublesome when comparing environments (e.g. DTAP), especially if effectively it is not used/needed for specific (parent) nodes

As practically every CMS configuration parent node, under /hippo:configuration/hippo:frontend, is either a frontend:plugincluster or frontend:pluginconfig, there are (too) many orderable nodes having the above problems.

To solve all this an alternative solution will be implemented which no longer needs the 'orderable' setting for the frontend:pluginfolder, frontend:plugincluster and frontend:pluginconfig node types.

Instead, a new optional frontend:pluginorder (double) property will be added to the frontend:plugincluster and frontend:pluginconfig node types, which then can be used to assign a specific ordering 'weight' to the specific child node.
Then, only for those child nodes for which this actually is needed, the ordering can still be controlled, relatively, without direct/explicit dependency on existence of sibling children.
Child nodes with a frontend:pluginorder then will always be ordered before siblings without such property (regardless their value).
And once the orderability of the children is removed from the node types, the order of the children without such property no longer will be guaranteed.

The tradeoff is: this requires changes (adding the frontend:pluginorder property) throughout the whole of the product stack, as well as proper documentation and upgrade instructions for existing projects how to 'wire' their customizations/extensions in the correct place.

The implemention of this new load ordering of the plugin(cluster)s will be done such that only if one or more child nodes have such property set, that ordering will be enforced, otherwise the (JCR) read order will be kept. This allows a gradual migration of the existing configurations step by step. Only when all the (product) configurations have been updated the orderability will be removed from the above mentioned node types.