MODE-1984 Corrected shareable node behavior upon removing a shared node

When a shared node is removed, ModeShape's behavior is that this is the same as calling `node.removeShare()`, which just removes the share and does not affect the other nodes in the shared set. However, when the primary node was removed, ModeShape was incorrectly removing the node from the repository, even though the parents of the other nodes in the shared set still contained references to the shared node.

In particular, the problem appeared to manifest itself only when the shared node was looked up by identifier and then removed. The resulting node was an instance of `JcrNode` rather than `JcrSharedNode`, and thus the remove logic `JcrSharedNode` was never called.

Quite a few small changes were required to fix the problem. First, two unit tests were added to replicate the incorrect behavior. Then, several smaller changes were required in a number of other classes. For example, the logic of removing a shared node was moved out of the `JcrSharedNode` class and into the JcrNode base class. However, this additional logic only kicks in if the node is `mix:shareable`.

While working on this fix, I discovered another subtle bug in how the SessionNode removed a child when that child had additional parents. This was corrected and validated.

The final challenge with this fix was that when `node.save()` was called on the parent (or ancestor) of the parent from which the shared node was removed, the changes to the shared node (which no longer appeared as a descendant of the saved node) were not being saved. The cause turned out to be that when the *primary* node was removed, ModeShape was not recording that the old parent was removed from the additional nodes, and thus the logic to determine which nodes are affected by the `node.save()` never discovered that the removed node used to exist below the saved node.

All unit and integration tests pass after these changes.