More robust against VM exceptions.

* clearly report an actor shutting down because of an uncaught exception
  using the Eclipse Error log
* gracefully handle the common VM exceptions.

This is not exhaustive (a handful of FIXME notes are still in the codebase),
but it is a step in the right direction and fixes a number of issues I've
been seeing lately.

Fixed #1001328, Refs #1001487.(cherry picked from commit a07bd6b388a3da86aebba7de3c236d7ab9b3a619)
Uses a specific scala version for the version updater
(cherry picked from commit 24a421ae59777bb6e679b6d543150e7c53747473)
Merge pull request #330 from dragos/isssue/tasks-disappear-1001401

Use Scala specific task markers.(cherry picked from commit f24829080cc91df340335f06280cbc3bc4c10973)
Do not force default location of -XpluginsDir in Scala Compiler Preferences

Trying to force the default location to the plugins directory containing the
continuations.jar plugin turned out to be a very bad idea (this was done as
part of commit SHA-cbfd82d874f998b7726fec895ad4d83194ad1e5b).

The issue is that the default location where the continuations.jar is stored
changes *each time a user updates the Scala IDE* and, when updating, the
*former location is deleted*. The net effect of this is that after upgrading,
all projects using the continuations plugin would report the following error

	`bad option: -P:continuations:enable` is reported

Simply because the continuations.jar can no longer be located.

The fix is to somewhat restore the former implementation wrt how we handle the
`-Xpluginsdir` compiler setting. Basically, the solution consists in not
showing the default value of `-Xpluginsdir` to the user in the Preferences
dialog, and pass this default to the different compiler instance we create
unless the user specifices a different location (in which case, we do use the
location provided by the user).

There is one more catch due to the current way `ScalaProject.scalacArguments`
is implemented (the method is used to pass the compiler arguments to the Sbt
builder). In short, the returned arguments are only the ones forces by the user
via the Preference dialog. Since the `-Xpluginsdir` default directory is
**not** shown in the Preference dialog, the Sbt builder would fail to compiler
projects with continuations enabled because it wouldn't know where to look for
the continuations.jar. Hence, I had to add some ad-hoc code to handle this
correctly in `ScalaProject.scalacArguments`.

This whole fix is far from ideal, but I want to keep the changeset as small as
possible to avoid regressions, since this commit should be included in the
upcoming 3.0.0 release.

By the way, all existing projects that were affected by the error should
restore the defaults (Preferences > Scala > Compiler and hit the Restore
Defaults button).

Fixes #1001030, #1000700
(cherry picked from commit aa2ecb9dd0fefc08ab540158e976b7a9c219843b)
Testing presentation compiler when project depends on continuations.jar

Added a couple of tests for making sure that the build compiler and the
presentation compiler behave the same when compiling projects that depend on
the continuations plugin.
(cherry picked from commit 514c2a5ab5f35c5ad935ee664da568e7dffa14db)
Merge pull request #333 from dotta/backport/3.0.0/cannot-enable-continuations-plugin-1001030

Backport/3.0.0/cannot enable continuations plugin 1001030
Lazy retrieval of Java parameter names in completions.

When a completion is selected we need to show the parameter names as placeholders.
If the method comes from Java, we need to retrieve the Java element, a potentially
long-running operation that can trigger the structure builder. Instead of retrieving
all parameter names eagerly, for each completion proposal, we delay it to the
moment a completion is selected and inserted in the editor.

Fixed #1001560, #1001497.(cherry picked from commit ffcf62afa48f6b775258493f5cc34e84e517d2e0)
Comply to the debugger interfaces by wrapping JDI runtime exceptions

Several of the debugger interfaces we implement expect a ``DebugException`` to
be thrown when the called method fails to execute. Failure can occur, for
instance, when a debugger session is terminated by the user. Failing to wrap
the JDI runtime exception in a ``DebugException`` can prevent the debugger to
correctly work and the user is sometime forced to restart Eclipse.

``DebugException`` is a platform exception that is specially treated by
Eclipse.

If you wonder why do we have calls to ``safeStackFrameCalls`` in, for instance,
``ScalaStackFrame.getLineNumber``, the answer is: I don't think we need it. However,
since we are in RCs cycle for the 3.0 release, I want to minimize the changes in
this commit to avoid regressions.

Fix #1001531
(cherry picked from commit 60df6af6ca83e83c8fee72146f19a064237df5b3)
Merge pull request #340 from dotta/backport/3.0.x/issue/handling-debugger-runtime-exceptions-1001531

[backport] Comply to the debugger interfaces by wrapping JDI runtime exceptions
Return `OK_STATUS` from the semantic highlighting job when the editor is dirty.

Previously, we announced that the job finishes asynchronously (`ASYNC_FINISH`),
but forgot to call `done` if the editor was dirty (and no UI asyncExec was
performed at all). This lead in turn to the job manager thinking that the job
is still running and not scheduling another run, ever, meaning the loss of
semantic highlighting.

Fixed #1001536.(cherry picked from commit 5e511529b0565dd27448a5bc07877d0120ddf679)
Expanding variable in debugger resulted in NPE

The regression was introduced by SHA: be83fc8f7c40c71269d5e7315594896e6b85ab69.

The reason for the regression is that the name of the class
``ScalaLogicalStructureProvider`` was inadvertently changed to
``ScalaLogicalStructureProviders`` (note the final **s**). Since that class was
linked to the *org.eclipse.debug.core.logicalStructureProviders* extension
point, as soon as the debugger code needed to load that class an exception is
reported.

What we should do to avoid this sort of errors in the future is setting the PDE
compiler flag for "References to non-existing classes" to *Error*. Furthermore,
it would be good if this check could be enforced in our Tycho build (I've asked
in the tycho-user ML,
[here](http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04110.html) is the
link to the discussion).

Fix #1001586

Backport to _release/3.0.x_
(cherry picked from commit ca3a67d8768d185ec5547ce4ddb77ab1a21709d8)
Merge pull request #346 from dotta/backport/3.0.x/issue/expanding-variable-in-debugger-view-produces-NPE-1001586

[backport] Expanding variable in debugger resulted in NPE
Disabled ``implicitConversionFromPackageObjectShouldBeInScope`` PC test

Disabling the test ``implicitConversionFromPackageObjectShouldBeInScope`` from
PresentationCompilerTest because it often fails on our Jenkins machine (and
that's just plain annoying), e.g.,
https://jenkins.scala-ide.org:8496/jenkins/job/parameterized-scala-ide/168/console.
This test has been flaky for at least a month now.

Re #1001588
(cherry picked from commit 02fbfe2347e4d83de6f84fc0b5cb6e44f5bec19e)
Merge pull request #348 from dotta/backport/issue/flaky-presentation-compiler-test-1001588

[backport] Disabled ``implicitConversionFromPackageObjectShouldBeInScope`` PC test
Don't add arguments templates for parameterless method's completion

When asking for completion on a parameterless method we were trying to install
arguments' templates. This operation in not allowed on parameterless methods,
and it caused a ``java.lang.IllegalStateException: must specify at least one
linked position`` during completion.

``explicitParamNames`` is a ``List[List[String]]`` (because of currying), hence
a parameterless method is represented as ``List(List())``. The arguments'
templates where added only if ``explicitParamNames`` is not empty, however a
``List(List())`` contains exactly one element (the empty list), hence it's
never empty!  The fix is really simple, we just need to flatten the
``explicitParamNames`` before checking for emptiness.

Fixes #1001591

backport to _release/3.0.x_

review by @dragos
(cherry picked from commit d08e999c47f4768179d63c99c7c06268fbea55c7)
Merge pull request #350 from dotta/backport/3.0.x/issue/ISE-during-code-completion-1001591

[backport] Don't add arguments templates for parameterless method's completion
Workaround for NPE in debugger variable view when using Eclipse Juno

Unfortunately, the way we keep track of the currently selected thread in the
Scala debugger isn't robust enough. Currently, we rely on a _selectionChanged_
event to be sent when the Debug Perspective is opened. This worked fine with
Eclipse Indigo, but it's no longer working with Eclipse Juno.

The workaround is to look for the first suspended thread if
``ScalaDebugger.currentThread`` is null. This is far from being a proper fix,
but it doesn't look like we have many alternatives. The Java debugger
implementation seem to be using a DebugContextProvider/Manager/Event/Listener
to know the thread associated to each variable. But using the debug context
classes would require some import work, so it would be preferable to delay this
for after the 3.0.0 final release.

The workaround was suggested by @skyluc, and he believes the only issue this
could lead to is visibility issues due to invoking a method call on the wrong
thread (in case more than one is suspended), and hence the executing thread may
see some stale values. Not an issue to be taken lightly.

Fix #1001585

backport to _release/3.0.x_
(cherry picked from commit 2de89febce7f9fb36820838b83f9ebd05fb0409d)
Merge pull request #352 from dotta/backport/3.0.x/issue/NPE-on-variable-view-with-Eclipse-Juno-1001585

[backport] Workaround for NPE in debugger variable view when using Eclipse Juno
Correctly search for threads, and don't use `Option.get`

JDI objects implement `equals`, we should not rely on reference equality.

This is the last instance of `Option.get` in the debugger.

Fixed #1001599.(cherry picked from commit 359aec26f5a2e36b86ab86aae9267ad9c01584f5)
Avoid workspace-wide locks when building.

There is no reason to lock the workspace when building a project. Markers already
lock the required resources, and the build should just lock the current project.

Fixed #1001631.