Correct regression error in ScalaCodeScanner

After refactoring the ScalaCodeScanner I discarded all white space
token because I thought it is an optimization (they must never
be colored). The offset error now occurres because of another
optimization that is done in a component built-in in Eclipse:
org.eclipse.jface.text.rules.DefaultDamagerRepairer. Whenever this
component detects style ranges of the same type that are consecutive,
only the first style range is applied and then expanded for all
following ranges. Because white space token are omitted it can be that
a color range is expanded although it is not allowed.

To correct the behavior white space token are not discarded anymore.

Fix #1001481
Merge pull request #293 from sschaef/issue/scala-code-scanner

Correct regression error in ScalaCodeScanner
Remove `Xmigration28` setting.

Fixed build for 2.10.1-SNAPSHOT.
Bump version number to 3.0.0-SNAPSHOT.

Once we bump the version, I can branch for release/3.0.x.

I removed some versioned dependencies between our own core plugins (sdt.debug
to sdt.core, sdt.spy to sdt.core), as I think they are not needed and are just
a pain to maintain.
Adds anon function and flags in cache

Creates an new map cache to store information about method containing the code
of anonymous functions, and method flags.
With tests.

Fixes #1001001
Merge pull request #295 from dragos/set-versions

Bump version number to 3.0.0-SNAPSHOT.
Merge pull request #296 from skyluc/issue/debugger-cached-method-flags-1001001

Adds anon function and flags in cache
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