Auto-export cannot differentiate between SNSs when processing journal events

JCR change events in the journal are ambiguous when SNS nodes are involved, and therefore auto-export must defensively check for changes on all siblings of any node that is mentioned by a change event.

For example, if A: a change occurs on node[3], then B: node[2] is deleted, and finally C: the session is saved, the resulting change events will both use node[2] as the source path. This is very counterintuitive when processing the events individually. It seems that a single node was changed, then deleted, and now continues to exist, when in fact these events refer to 2 different nodes.

Note that this confusion can still occur with events that do not have a SNS index in the node path. (change node[2], delete node[1], and save -> all changes use "node"). Therefore, we must check for the possible existence of sibling nodes for ALL nodes we process, and then interrogate the JCR to determine the actual state of these nodes. Furthermore, SNSs could be involved in the ConfigurationModel or the current JCR state, and so both must be consulted.