Rethinking the :adjust hint

> I think we need a separate hint: The adjust hint bears the problem that changing a start date towards the past might accidentally delete other intervals, at the same time if you have two intervas back to back and you want to move the start time of the latter one back, it should do that without complaining.

As mentioned in https://github.com/GothenburgBitFactory/timewarrior/pull/329#discussion_r446508616 I think we need more fine-grained adjustment. There I suggested splitting it into two hints, `:adjust` and `:override`, where the former only allows adjustments but no deletion of intervals.

Now that I reconsider it, I think that this behavior should be default. When I track, I frequently have to adjust afterwards, and even if I do a mistake there - as long as no interval is deleted, it is very easy to adjust back.
So I would actually propose to have a `:noadjust` hint and a `:override` hint with the default being to allow non-destructive adjustments. This would also make the backwards-compatibility break more explicit.

Start by reading the current :adjust hint behavior and the discussion in pull request #329, especially the referenced review thread. Trace how :adjust, :noadjust, and :override are expected to interact with adjacent intervals and deletions. Done requires an agreed behavior and corresponding implementation and tests for the backwards-compatibility change.

Written by the indexing model from the issue text.