Adds a preference for the classpath validator

The preference allows to disable the search for jars not compatible with the current version of Scala.
Limits the check to possible version of Scala >=2.8.0.

Fixes #1001482
Adds an extractor to check incompatible versions

The code is more self-contained.
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.
Adds documentation to classpath validator.
Merge pull request #303 from skyluc/issue/classpath-validator-preference-1001482

Adds a preference for the classpath validator
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
Clean projects in a background job when project settings' change

Cleaning the projects in the UI Thread was causing UI freeze. The
fix is really simple: clean the projects in a background job.

Note: The implemented solution is inspired by the Eclipse
      ``CleanDialog`` component.

Fixes #1001527
Merge pull request #323 from dotta/issue/project-settings-should-not-trigger-rebuild-in-ui-thread-1001527

Clean projects in a background job when project settings' change