Incorrect order of logic in ContentTypeService ContentType definition merging

The ContentTypeService can dynamically 'create' (derive) a ContentType definition for an existing node, based upon its primary type and additional mixins.
If such aggregated ContentType is not fully predefined as document type in hippo:namespaces (for example in case an extra mixin is defined on the node),
the ContentTypeService will build a new aggregated ContentType (and cache it thereafter) by combining (merging) predefined ContentTypes to match the 'makeup' for this specific node.

The order in which these predefined ContentTypes are merged should not be relevant, however there is a bug in the existing logic which does cause this order to be significant, and
as result then can cause it to 'skip' merging certain properties and children of the content type to be merged, and thus resulting in an incorrect derived ContentType.
Note, this only can happen for dynamically derived ContentTypes, e.g. when invoking ContentTypes#getContentTypeForNode(Node), not for the predefined ContentTypes.