Improving propagation of structural changes during reconciliation

Nobody has claimed this yet.

**Describe the Feature**
When applying structural changes to components, we currently only have rudimentary handling of how these structural changes are reflected in the derived components.
The reconciliation algorithm needs to be improved in the following areas:

1.) What does removing a morph do to all of the components down the derivation chain (The children, grandchildren etc...) entail? What happens to the parts that used to have customisations within derivations but are now gone?
2.) What does moving a morph within the component definition, (so just changing the parent) entail for all of the derived components? Are the customisations preserved?
3.) What does replacing a morph within the component definition entail? Do we need a particular `replace` command for that? Is replacement automatically triggered by removing, adding and naming the new morph the same? What does it entail for all of the derived components?
4.) What needs to be kept in mind is also a tradeoff between *correctness* and *usefulness*. What I mean by that is, that not any imaginable behavior of the reconciliation is good if it is *correct* in a formal sense. We may run into scenarios that although they
resolved correctly, are utterly confusing to the user.

Start by locating the reconciliation algorithm and tracing how structural changes in component definitions are propagated to derived components. Work through removal, movement, and replacement scenarios, including existing customizations and the tradeoff between formal correctness and user usefulness. Done means the behavior and replacement semantics are defined for the derivation chain.

Written by the indexing model from the issue text.