Make semantic highlighting faster by using the Trees directly. Some tests still fail, mostly by mis-classification of symbols that stand for different things.
Try to minimize the number of symbols that are selected for highlighting. Made safe the SymbolTest class (companionClass is not thread-safe).
Optimization: Reduce number of time a Scala source is marked as changed

Marking a Scala source as changed may trigger reconciliation, which can
be a costly operation at this time since as the semantic actions are run
in the reconciler thread.

More importantly, a source should be marked as changed only if some change
really occurred, that's why we now check if the source's ``delta`` has the
flag ``IJavaElementDelta.F_CONTENT`` set.
Minor refactoring in ``SymbolClassification`` and ``SymbolTests``

The ``Selections`` trait was mixed-in to get access to the methods in
``PimpedTrees`` (which ``Selections`` mixes-in). Hence, I removed the
``Selections`` trait and mixed-in ``PimpedTrees``, which is all
``SymbolClassification`` class really needs.
Turned ``SemanticHighlightingReconciliation`` into a class and using ``java.util.concurrent.ConcurrentHashMap`` in place of Scala ``SynchronizedMap``.
remove only the compilation unit that has been closed
minor refactoring
Minor refactoring: Added a ``SemanticAction`` pure interface implemented by the
semantic action classes.
Semantic Highlighting symbols' classification should not skip synthetic
symbols.

In the attempt of optimizing semantic highlighting, synthetic symbols were
being skipped. That seemed to be a valid optimization, since synthetic symbols
are associated to compiler injected definitions (which are hence not visible in
the source code). However, user code may be use the synthetic definitions, and
therefore it is not safe to filter away synthetic symbols during
classification.

For instance, in the following example

```
case class CaseClass(n: Int) {
    CaseClass(42) // <- this reference the companion object, which is a synthetic symbol
}
```

``CaseClass(42)`` is actually referencing the companion object of the class
``CaseClass``. The companion object has not been declared in the source, hence
it is injected by the compiler, and a synthetic symbol will be used to
reference it.

On the other hand, it looks safe to skip anonymous function's symbols.
Correctly retrieving the symbol associated to an ``import`` clause.

I believe you will agree that finding the *right* symbol it's a interesting
challenge in the case of an ``import`` clause. In a nutshell, the only way to
know whether the imported ``name`` is referencing a class is to check if the
symbol associated to ``expr.tpe.member(name.toTypeName)`` actually ``exists``.
If it doesn't then the ``name`` must be referencing a module.

There is one more issue with the way we resolve ``import`` clause: we are not
correctly manipulating clauses like ``import scala.Option._``. This still needs
to be fixed.
Correctly differentiate field declarations and parameters.
Correctly categorize types that take type parameters.

Fix #1000938.
Tree.namePosition can be called only on visible trees (i.e., trees with a RangePosition).
Coloring fully-qualified annotation's type with a single color (though, it may be better to color only the type, and not the packages)
more tests yet to be fixed for import clause
Coloring only the annotation's type.
Ignoring tests that are currently failing.

Here follows a description of the current main point of pain:

* packages are sometimes tricky to color. The main reason I can see is that sometimes the associated symbol has a TransparentPosition (symbols with TransparentPositions are filtered during the classification)
* types inside ``classOf`` are currently not correctly colored.
* package object seem to be trycky.
* Import statements are difficult to handle correctly in general.
Corrected classification of ``var``s.

A ``var`` that gets accessed through its getter (remember, a ``var`` gets
always compiled into a getter and a setter by ``scalac`` - uniform access
principle) must be classified as a variable (either TemplateVar or LocalVar).

The difficulty is that when a ``var`` gets accessed through its getter, the
symbol handle we have in the ``Tree`` is a ``MethodSymbol`` for the getter.
Therefore, to decide if behind a getter sits a ``val`` or a ``var`` we need to
check if the symbol's owner (i.e., the getter's owner) contains a setter method
that matches the getters' name (this can be done using the compiler method
``nme.getterToSetter``).

Fixed #1000958.
Minor refactoring

Following Mirko's suggestion in @0e477495713d89114c9541170f446d22a3f2bcfe, using now
``sym.setter(sym.owner)`` for finding the setter of a getter.