Repoinit should support 'allowUpdate' option with node type registration

JCR node type registration as defined with NodeTypeManager#registerNodeType and NodeTypeManager.registerNodeTypes comes with a boolean flag that specifies how to handle existing node type definitions upon registration. However, Sling RepoInit does not support the 'allowUpdate' flag and there is no way to update an existing nodetype definition through RepoInit. Consumers of the API need to resort to programmatically update the node type using JCR API in a service.

Here the extract from the specification (copied from https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/19_Node_Type_Management.html):

19.2.4 Registering a Node Type

NodeType NodeTypeManager.
registerNodeType(NodeTypeDefinition ntd, boolean allowUpdate)

registers a new node type or updates an existing node type using the specified definition and returns the resulting NodeType object. Typically, the object passed to this method will be a NodeTypeTemplate (a subclass of NodeTypeDefinition) acquired from NodeTypeManager.createNodeTypeTemplate and then filled-in with definition information. If allowUpdate is true then an attempt to change the definition of an already registered node type will be made (see §19.2.4.1 Updating Node Types), otherwise an attempt to register a node type with the same name as an already registered one will fail immediately.

NodeTypeIterator NodeTypeManager.
registerNodeTypes(NodeTypeDefinition[] ntds,
boolean allowUpdate)

registers or updates the specified array of NodeTypeDefinition objects. This method is used to register or update a set of node types with mutual dependencies. It returns an iterator over the resulting NodeType objects. The effect of the method is “all or nothing”; if an error occurs, no changes are made.

19.2.4.1 Updating Node Types

A repository that supports node type management may support updates to a node type already in use as the type of an existing node. The extent of any such capability is implementation dependent. For example, some implementations may permit only changes which do not invalidate existing content, while others may allow larger changes. How any resulting incompatibilities are resolved is also implementation dependent. Any changes to the type of an exiting node must take effect in accordance with the node type assignment behavior of the repository (see §10.10.1 Node Type Assignment Behavior).

We would therefore suggestion to either add an optional 'allowUpdate' (or 'reregister') flag the existing register nodetypes command (default would be 'false' to ensure backwards compatible behavior) or introduce a new command reregister nodetypes.

Original use case from cschneider:

My use case is to extend an existing mixin with an additional property. 
For new repositories this works but for existing repositories the existing mixin is unchanged.
As my code requires the new property I get errors.

So I propose that repoinit allows to update existing mixins (and possibly other structures).