Change recorder generates incomplete change list on cascade deletion

[JanWittler]

If there is an element a containing the element b and a is deleted, both a and b get deleted because b is contained by a. However, the EMF notification system does not generate any notifications for deleted objects (nor created). As a result, we generate the delete changes ourselves when finishing change recording in the ChangeRecorder.
With #48 we added support for generating delete changes for cascade deleted elements. However, this is not complete as any deletion is preceded by removing the deleted element from its container.
This becomes a problem when applying changes backwards. For a cascade deleted element, it is created when applying the delete change backwards but never inserted into its container as that particular change (i.e. some RemoveEReference / ReplaceSingleValuedEReference) is missing.

Expected result

Recording deletion of a containing b yields change sequence: DeleteEObject(b), RemoveFromContainment(b), DeleteEObject(a) where RemoveFromContainment(_) has to be the appropriate change type depending on the feature that b is contained by (single-/multi-value).

Actual result

Recording deletion of a contains b yield change sequence: DeleteEObject(b), DeleteEObject(a).

Misc

• The container and contained in feature of an element are accessible through EObject::eContainer() and EObject::eContainingFeature
• The problem currently never appears as we apply changes only backwards when generating hierarchical IDs. As we cache deleted elements there instead of creating new ones (what would be the proper way) the problem does not occur.