2_4 delete insert+use needs more clarification

before detecting conflicts, all move operations are detected form delete-add operations

### **Question**
BUT should the delete insert-use really be detected as move, then the info of the insert gets lost, but if it not detected as move, the info gets lost that it is actually the same relation

### **Current Behavior for move conversion**
Currently the move detection out of delete-add is done by comparing the ids of delete-add if they are the same, if delete-add is just the reference, the reference id should be the same

### Problem
But with delete insert+use these are the initial operations:

```
// DELETE:
{ "value":{"id":"category","containment":true,"upperBound":-1,"lowerBound":0,"type":{"$ref":"#/package/classes/2"}} }

// ADD:
{ "value":{"id":"InfrastructureComponent","references":[{"id":"category","containment":true,"upperBound":-1,"lowerBound":0,"type":{"$ref":"#/package/classes/2"}}]}}}
```

`InfrastructureComponent` is the new class that was added, and `category` is just the reference that was moved.
The first level ids do not match, it would need some more complex code.

### Possible best Solution?

-before conflict detection, detect the move, but split it from the add somehow

Thats what the unit test currently expects.

----

For the conflict detection in such a case:
- delete add operations will not be merged
- BUT it will still detect a conflict, then its a `delete use` conflict

I think this behavior is fine for now.

Start with the current unit test for move conversion and trace the conflict-detection path that converts delete-add operations into moves. Compare the shown DELETE and ADD shapes, then clarify whether move information and insert information must both be preserved; done means the agreed behavior is covered by the unit test and delete-use conflicts are detected as described.

Written by the indexing model from the issue text.