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
Java Semantic Highlighting can be disabled without using aspects
Deprecated ``SemanticHighlightingReconciliationPartecipant``s
Included 1-round reviewer comments
Issues:
* Needs to pick up user's coloring changes