[JcrDiff] Node reordering using node position is broken and fundamentally unreliable

The jcrdiff tool tries to keep track of the node order position to be able to restore this position when applying a patch.
However, the current implementation is:

• broken
• fundamentally unreliable

1) The rather extensive PatchSerializationStressTest, which generates random changes in a (JCR) tree, generates and serializes a patch for it, and then tries to apply that patch to restore the changes,
afterwards asserts the tree is equal again to its original structure.
However, the PatcherTest.assertTreeAreIdentical(targetTree, sourceTree) method is not checking the resulting ordering of the nodes.
And neither is it properly catering for potential same-name-siblings and/or a node and property with the same name...
When comparing the node ordering is added to this check, it becomes clear the current implementation is not working correctly, e.g. broken!

2) Using the current node position to try restoring the node ordering through a patch is not, and cannot be, reliable.
The JCR engine nor specification has any (persistent) notion of node position, only of a relative ordering of nodes.

Trying to restore a specific node ordering using node position therefore is unreliable and none-deterministic, as the current repository can have a completely different order (and number of node siblings) than at the time of the patch creation.

The only reasonably reliable way to restore node ordering therefore should leverage the (only) support provided by the JCR specification: using the relative ordering between sibling nodes with (parent) Node.orderBefore(srcChildRelPath, destChildRelPath).