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.
Merge remote-tracking branch 'origin' into platform/juno