Don't crash if the class user doesn't clone the incidence.

Before the ItemModifyJob the incidence is modified, and usually
it's not a clone, so the one inside the calendar gets changed too.

This is cool but has a little downside that the calendar looses
the original RELATED-TO information in case the user re-parents
the to-do.

With this commit we now keep the uid->parentUid mapping so we can
detect when a dataChange() changed the RELATED-TO field, so we
can update the hierarchy info so childIncidences() works.

Updated the unit-test not to clone.