Make stepping as fast as in the JDT debugger.

Two performance improvements in the way we handle stack frames:

* make `variables` lazy. This way we don't retrieve variables values
  unless they are needed (most of the times, they are needed for only one
  frame in a full thread stack). Retrieving values requires a roundtrip
  to the debugged VM, hitting the network stack.

* don't fire DebugEvents for creation of stack frames. This is the
  time consuming part: each frame (can be hundreds) fires one CREATE
  event that is put in a queue and a job-dispatch is scheduled to run for
  *each* frame in part. This floods the event queue and leads to
  lag times in the order of seconds (depending on the stack depth).

I checked (in the debugger) that the JDT debugger does not fire CREATE
events for stack frames, so I'm suggesting we do the same thing.
Merge pull request #317 from dragos/performance/stepping-improvements

Make stepping as fast as in the JDT debugger.
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.
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``.
Java Semantic Highlighting can be disabled without using aspects
Deprecated ``SemanticHighlightingReconciliationPartecipant``s
Uses sbinary '-pretending-SNAPSHOT' version
Merge pull request #320 from skyluc/issue/sbinary-pretending-snapshot

Uses sbinary '-pretending-SNAPSHOT' version
Merge pull request #321 from dotta/issue/dont-use-annotation-model-for-semantic-highlighting-1001156

Issue/dont use annotation model for semantic highlighting 1001156