Fix #411 Execution nesting changes

[cdamus]

Fix a variety of edit scenarios involving execution nesting, including:

• don't allow partial overlap of execution specifications. Nesting must be complete or not at all
• ensure that executions dropped onto other executions result in proper nesting, whether the
  execution dropped is smaller than (nested within) or larger than (nesting without) the execution
  on which it is dropped
• the previous item applies equally to executions dropped onto executions on other lifelines as
  on the same lifeline

This also includes some incidental changes unrelated to Issue #411:

• issue Nudging an execution nudges down also nested executions #422 (fixing it was required for proper recalculation of executions in other drag/drop scenarios)
• JUnit tests that have been skipping on assumption violations since the merge of changes to the anchoring of delete messages (I worried that it was a regression introduced by changes in this PR, but that turned out not the case)

[cdamus]

I had already checked that this can still be merged even after #426. 😉

[rschnekenbu]

Hi @cdamus, indeed, this PR merges perfectly with the work on #426 ;-)

Works good, I only have a small glitch when uncovering a nested execution:

before

after - note the execution which is still located on its previous X location compared to the middle of the lifeline.

Finally, I have detected a regression on the pop up menu when creating a sync message from an execution, but it seems related to the work on #426 if I dig into the history.

I can create a new bug out of this last comment, as this should probably not be handled in this PR.

[cdamus]

Thanks, @rschnekenbu ! The misaligned execution should be easy to fix. I expect the popup menu problem is caused by regeneration of the model. Oops. 😳

[cdamus]

Thanks again, @rschnekenbu. I've pushed a new commit that fixes the problem of the carpet swept out from under a nested execution.

[rschnekenbu]

Looks good to me ;) Thanks for update on this PR!