No longer using the AnnotationModel for semantic highlighting

The former implementation of semantic highlighting was extremely slow for
several reasons:

First, the annotations, created by the semantic highlighting component, where
invalidated and recomputed every time the compilation unit was reconciled.
Second, the current implementation of the AnnotationModel , adding/removing an
annotation is O(n^ 2). (The quadratic behavior is due to the implementation of
``CompilationUnitDocumentProvider#ReverseMap``, which is used by
``CompilationUnitDocumentProvider#CompilationUnitAnnotationModel#addAnnotation``.
Basically, each time an annotation is added/removed, the ``ReverseMap`` class -
which is backed by a linked list! - is accessed to verify if the element
exist.)

The proposed solution is to use the document's model to keep track of
semantically highlighted positions, and use a ``TextPresentation`` to
invalidate the editor's region that is affected by the user's edition (if any).
This approach is much more lightweight and it turns out to be much more
efficient than the former.

As a further optimization, instead of invalidating all semantically highlighted
positions each time, a listener (``DocumentProxy$HighlightedPositionUpdater``)
is registered on the document to keep track of document's content changes and
update (through side-effects) all highlighted positions (that are not affected
by the edition) held by the document.

Bottom line, with the current implementation semantic highlighting is:

* Considerably faster.
* Never flickers.
* Testable.

Last thing, as part of this commit I've added the needed infrastructure for
registering reconciling listeners (i.e., ``IJavaReconcilingListener``) to the
editor.

Fix #1001156
Included 1-round reviewer comments
Java Semantic Highlighting can be disabled without using aspects
Deprecated ``SemanticHighlightingReconciliationPartecipant``s
Encapsulates all logic that touches the document's positions in an actor

This was done to avoid that document's positions could be read/write in
parallel by different threads. This was very possible in the former implementation,
because both the `Presenter$Reconciler` and the
`DocumentProxy$HighlightedPositionUpdater` (which used to run in the UI Thread)
could be stepping on each others while performing some computation on the
highlighted positions.

This fix should finally prevent half-colored identifiers. Furthermore, I think that having
a single place that touches the document's position does simplify reasoning about this
code and will ease maintaining it.

Minor note: I had to add a `Thread.sleep` in the testing code to give some time to the
actor to run.

Some other facts about this commit:

* No need for TextPresentationEditorHighlighter to extend InteractiveCompilationUnitEditor
* Improved documentation
* No need to call reconciler.cancel in `PerformSemanticHighlightingOnReconcilation.reconciled`