[Proofreading] Improve merge speed by not awaiting roundtrips

[philippotto]

Currently, a merge operation:

• blocks the user by entering a busy state
• adapts the mapping locally (the rendered data is updated directly)
• ensures a saved state (so that later mapping-requests provide correct values)
• unblocks the user

Multiple ideas to improve this:

Idea 1: Don't ensure a saved state

• when merging two ids A and B (e.g., so that B is changed to A) one can adapt the results of mapping-requests (that the server sent without knowing about the merge) by reassigning B to A
• ensuring a saved state would not be necessary anymore then
• however, split operations would need a new synchronization point (before and after the split; previously it was only after the split). the before-sync is only needed when a merge wasn't saved yet.

Idea 2: Don't block the user while ensuring a saved state

• the user should be free to move around and inspect stuff. nothing bad should happen when only a save is pending. they don't need to know that wk is waiting for a save.
• if the user does a split-operation after a merge, the merge needs to be awaited before the split operation is sent to the server, though. thus, we would defer the synchronization point.

Both ideas introduce additional complexity. I'd prefer doing (1) for now, since I have a bad feeling about dissolving the busy-blocking.

[hotzenklotz]

@philippotto Is this issue completed with the recent magic mappings PR?

[philippotto]

no, unfortunately not. this issue was created to suggest further improvements for the "magic mappings" performance. probably not high-pri for now, but it could definitely make the merge operation more snappy (think old merger-mode style).