Scala debugger working without JDT debugger

Reworked the Scala debugger so it doesn't use the JDT debugger to
communicate with the VM.
A new launch delegate is added to the Scala application launch configuration type.
It creates a ScalaDebugTarget from the JDI connection to the vm.
Added a breakpoint manager, to create and delete the JDI requests needed.
Added a JDI event dispatcher, to pull the events from the JDI event queue and forwarding
them to the interested parties.
The management of the events and of the state of the debug elements is base on Scala actors.
Removed the debug preference page
Improved the access modifiers

Fix #1001130
Fixed defaults:

* CMD-Shift-S T was conflicting with `Save all`. Now it's CMD-Shift-W T (Show Type)
* lighter shade of grey for implicit highlighting
* Renamed 'Active' to 'Enabled' on the preference page.

Fixed #1001023.
When collapsing imports, also sort the import selectors.

Fixes #1001155.
Merge pull request #156 from misto/issue/sort-selectors-1001155

When collapsing imports, also sort the import selectors.
Updated following pull request comments

Uses vals wherever possible
Create and initialize instances using companion object apply methods
Fixed missing ()
Thread safe info
Merge pull request #155 from dragos/issue/fix-defaults

Fixed defaults:
Added more missing parentheses

Re-enabled tests disabled by mistake
Merge pull request #153 from skyluc/issue/scala-debugger-without-JDT-1001130

Scala debugger working without JDT debugger
Made the Launchable Property tester use the presentation compiler.

This makes the Debug As/Run As menus much faster. It was not uncommon to wait for many
seconds when hovering over those menus. Added a bunch of tests as well.

Fixed #100818, #100082 along the way.
Remove the JUnitTester from the source code.
When renaming a setter or variable, display the getter name.

Fixes #1001177
Small refactoring/clean-up in ``ScalaMatchLocator``
Fix #1001173, #1001174 - Correctly expose abstract val/var to JDT

Abstract val/var were being ignored in the ``ScalaStructureBuilder`` and
therefore no ``IJavaElement`` was being created. Indeed, abstract val/var are
represented in scalac as ``DefTree``, and the attached symbol has the ACCESSOR
flag set (that because the symbol that is attached to abstract val/var is
always the getter symbol, i.e., its accessor).

The fix consisted in simply not pruning ``DefTree`` that have the ACCESSOR flag
set (this fixed #1001173).

A nice side effect of the fix is that missing implementation of abstract val/var
are now reported in Java sources (which fixes #1001174).
Method references inside closures are now correctly reported
References of abstract fields are now correctly reported

Abstract fields cannot be represented in JDT (Java doesn't have abstract
fields, only methods can be abstract).  Therefore, when looking for the
``IJavaElement`` of an abstract val/var, its accessor (i.e., the getter)
is returned instead.
References of anonymous classes are now correctly reported

* Do not update the ``currentOwner`` for type bounds.
* Set the ``currentOwner`` of an annotation to be the member/class
declaration to which the annotation is applied to.
* Use ``getJavaElement`` instead of ``getElementAt`` for finding the
enclosing ``IJavaElement`` to be reported as result of the search.
Refactoring in FindReferencesTests
Re-enabled a few test
In ``testSearchIndexAnnotations``, look for exact matches of ``org.junit.Test``

This is a detail, and both ``SearchPattern.R_PREFIX_MATCH`` and
``SearchPattern.R_EXACT_MATCH`` work fine.  However, I think the latter better
express the intention of the test.
Correctly index referenced to var's assignments (i.e., calls to the setter)

When looking for reference of a field assignment, both calls to the var's
setter (i.e., assignment) and getter should be returned. For this to be
working, the ``ScalaIndexBuilder`` is now checking if the name of a ``RefTree``
is a setter name, and if that is so a reference to the getter name (which is
the actual field name) is instead added in the indexer.

An additional interesting point is the element selection in the editor. When in
the editor the user right click on an element to find his references, the
symbol attached to the selected code element is typecheck, and in the case of
an var assignement the typechecked symbol is the setter symbol, while for the
very same untyped (i.e., not typechecked) tree node the attached symbol is the
getter symbol.

In ``ScalaCompilationUnit.codeSelect`` setter symbols are turned into getter
ones because the ``ScalaIndexBuilder`` does not indexes the setter name, but
only the getter name (which is the actual var's name), as explained in the
first paragraph of this commit.