order-before definitions should not be applied to JCR if the parent node doesn't support it

29.08.2017 11:53:59 WARN  localhost-startStop-1 [JcrContentProcessor.apply:145] Content definition processing failed: /content/documents/errorpage
javax.jcr.UnsupportedRepositoryOperationException: child node ordering not supported on node /content/documents

While the above WARNing is logged, it also throws an exception, causing the processing for this definition to fail.

However, we can and should check if order-before is allowed, and in case it is not we can be more lenient and only log a warning. 

An additional and quite tricky side-effect of the existing (non) error handling is that after a content definition is skipped loading for the above reason, a subsequent content definition which should be ordered-before the previously failed definition then will fail because that sibling node doesn't exist (in JCR).
The second failure itself however is not the real problem, the error handling however is: it throws an IllegalStateException which causes it to 'bubble up', skipping the try...catch (RepositoryException) handling in the invoker ConfigurationContentService#apply() method, and as result not clearing the existing JCR session state (with session.refresh(false)).
End of the story then is: there is (or can be) still pending changes in the session, after applying (all) the content. 
Which isn't allowed by the PostMigrators processing which require a 'clean' session state to begin with.
Fix is trivial: instead of try..catch(RepositoryException) do try..catch(Exception) in ConfigurationContentService#apply() method