Faster and slicker Semantic Highlighting

The former implementation of semantic highlighting was slow becuase of the
following two reasons:

First, the annotations created by the semantic highlighting component, where
invalidated and recomputed every time the compilation unit was reconciled.

Second, for 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 apply semantic colorings directly on the editor's
``TextPresentation`` and hence no longer use the ``AnnotationModel``. This
approach is both lightweight and orders of magnitude more efficient than the
former.

The way semantic highlighting works now is relatively simple. At a high level,
there are only three key elements:

* ``Presenter$SemanticHighlightingJob``: Given a compilation unit, it
  classifyies and collects all positions that need to be colored in the editor.

* ``PositionsTracker``: Keeps track of currently highlighted positions in the
  editor.

* ``TextPresentationEditorHighlighter$ApplyHighlightingTextPresentationChange``:
  Converts them into   ``StyleRange``s, and applies the styles to the editor's
  ``TextPresentation``.

Of course the actual implementation contains a bit more than just the above
mentioned classes, but most of it is needed to correctly handle platform's
events such as the swapping of the document input (see
``Presenter$DocumentSwapListener`).

There is however one important optimization that is worth mentioning, which is
done to reduce to a minimum the editor's region whose styles need to be
refreshed. Basically, whenever the user is typing in the editor, all positions
that are **after** the cursor should be invalidated. If you are editing the
beginning of a big file, almost the whole editor's text presentation would need
to be refreshed. Furthermore, the mentioned approach would cause colors to
flicker because all highlighted positions **after** the edit would be deleted
(and hence the colors would be removed), and the new positions would get
colored only **after** the semantic highlighting job completes. This is clearly
not ideal, and it turns out it can be easily avoided by registering a
``IPositionUpdater`` on the editor's document. The concrete implementation of
the listener (i.e., ``Presenter$PositionUpdater``) takes care of shifting -
through side-effect - all currently highlighted positions that are **after**
the edited region. The net effect is that colors never flicker.

Bottom line, with the current implementation semantic highlighting is:

* Considerably faster.
* Never flickers.
* Testable.

If you wonder why the semantically highlighted positions are not stored in the
document's model, the answer is that I simply could not see any benefit of
doing so (why? because the document synchronizes access to the underlying
position's map when adding/removing positions).  Furthermore, it is really easy
to add the missing logic for storing the positions in the document's model, if
in the future it turns out we need/want to do so.

Fix #1001156

Other facts about this commit:

* Added the needed infrastructure for registering reconciling listeners (i.e.,
  ``IJavaReconcilingListener``) to the editor.

* Created a ``UiThread`` trait needed for testing code that needs to be run
  within the UI Thread.

Other tickets fixed by this commit:

* Disabling semantic highlighting in the preferences now refreshes currently
  opened editors. Fixes #1001507

* Changing semantic highlighting style's preferences now refreshes the
  currently opened editors. Fixes #1001508

* Cache highlighting styles instead of creating the during
  ``TextPresentationEditorHighlighter.ApplyHighlightingTextPresentationChanges.applyTextPresentation``.
  This optimization has major consequence on the user's experience. I should also
  point out that ``ScalaSyntaxClass`` and ``SymbolTypes``  are quite messy and
  should be improved. However, I think this should be tackled in a different PR.
  Fixes #1001493, #1001489.
(cherry picked from commit 9bfeb02fb7dda1be1fc526f014a7695fa29c988e)
Disabled Java semantic highlighting in Scala source attachments

Preventing the Java semantic highlighting engine to be installed
on Scala sources attachments.

By doing so, ``ScalaPresentationReconciler`` can now inherit from
``PresentationReconciler``.
(cherry picked from commit 4ba2ba92c2de31fd11dbc62ae0d3b1b28bd194b3)
Java Semantic Highlighting can be disabled without using aspects
(cherry picked from commit 05956d4a069b18494837e3d7214de23c2323f993)
Deprecated ``SemanticHighlightingReconciliationPartecipant``s
(cherry picked from commit 87e20d56713a3fe32f3bcf41637f24aa4f4c2a31)
Merge pull request #324 from dotta/backport/3.0.x/dont-use-annotation-model-for-semantic-highlighting-1001156

[backport] issue/dont-use-annotation-model-for-semantic-highlighting-1001156