Added back `def classpath`.

This should make ScalaTest plugin compile against both 2.0.x and 2.1.x.

review by @skyluc
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
Added `Implicits.scala` to the memory leaks test.
Bumped Sbt version to fix the 2.10 nightly.
Some code cleanup

* Removed unused methods.
* Renamed ``Scalaproject.initialize`` into ``ScalaProject.initializeSettings``
* Improved encapsulation of members.
Optimization to log an exception at most once if the same exception is being
(re-)thrown several times

This used to be an ad-hoc optimization available only in
``ScalaCompilationUnit``.  However, I believe this can be useful in general,
and the optimization belongs to ``EclipseLoggger``.

The former implementation was thread-safe because ``lastCrash`` was always
accessed within the ``PresentationCompilerThread`` (thread-safety was achieved
via thread-confinement). However, it was a weak form of thread-safety, as it
was potentially very easy to break if you didn't understand the thread policy
of the class (which is not documented).  Implementing this optimization in
``EclipseLogger`` forced us to have a stronger form of thread-safety, because
``lastCrash`` can be accessed from any thread.

Documented thread safety guarantees of ``EclipseLogger`` and also described its
synchronization policy for mantainers
Fixed exception occurring when deleting or closing a Scala project

Issue Description
.................

The issue was occurring only when a source was open in the editor and the
corresponding project was deleted/closed. Apparently, when deleting/closing a
project, any of its opened sources can still be reconciled (this only happens
if you have the Java breadcrumb enabled in the editor). The problem with
running the reconciler on a virtual source (i.e., the source does no longer
exist in the filesystem) is that the reconciler participants (e.g., semantic
and implicit highlight presenters) expect the source file to phisically exist.
When that's not the case, a ``java.lang.IllegalArgumentException`` was thrown
to the user's face.

Implemented Solution
....................

The current fix is to check in ``SemanticHighlightReconcilationParticipant``
that the compilation unit is linked to an existing (and currently opened)
project (i.e., the project actually exist in the filesystem).

Mind that this is actually *not* a proper fix, but a workaround. The problem is
that the ``SemanticHighlightingReconciliation`` mantains a map of
``ScalaCompilationUnit`` to ``SemanticDecoratorManager``, and the map is not
properly cleaned when a project is deleted/closed.  This is a memory leak and
the only way I see to properly fix this is to completely re-work the way
semantic highlighting is executed (Re #1001156).

Improvement
...........

Furthermore, when a Scala project is about to be deleted, the Scala project is
now disposed (i.e., the presentation compiler is shut down). This was not
needed to fix the issue described in this commit, but it seemed a valid
optimization.

Tests
.....

Unfortunately, the changes cannot be tested in a UI-less environment, hence no
tests.

Fixed #1001058

Integrated comments from pull #154
Use the existing method (with the correct workspace-locking behavior) to delete test projects.

..in the hope that some flaky tests will be less flaky.
Fixed #1001157.

Switched to `scala.tools.nsc.MainGenericRunner` instead of the deprecated `MainInterpreter`.
Updated comment.
Merge pull request #150 from dragos/add-back-deprecated-classpath

Added back `def classpath`.
Export all packages from sdt.core.
Only react to part-closed events related to the current project.

This regression manifested by having a Scala compiler started on all Java projects when
a file was closed. Annoyingly, that lead to the FailedCompilerInitialization window asking
about adding the Scala library.
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