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
Merge pull request #338 from dotta/issue/handling-debugger-runtime-exceptions-1001531

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.
Merge pull request #341 from dragos/issue/lost-sem-high-1001536

Return `OK_STATUS` from the semantic highlighting job when the editor is...
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_
Merge pull request #345 from dotta/issue/expanding-variable-in-debugger-view-produces-NPE-1001586

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
Merge pull request #347 from dotta/issue/flaky-presentation-compiler-test-1001588

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
Merge pull request #349 from dotta/issue/ISE-during-code-completion-1001591

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_
Merge pull request #351 from dotta/issue/NPE-on-variable-view-with-Eclipse-Juno-1001585

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.
Small improvement in ``CompletionTests`` test runner

If the test does not contain at least one occurrence of the expected marker,
fail the test.
Merge pull request #353 from dragos/issue/fix-none-get-101599

Correctly search for threads, and don't use `Option.get`
Auto delete closing character literal

Fixes #1001600
Auto delete closing string literal

Fixes #1001583
deletion of unnecessary method
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.
Merge pull request #360 from dragos/issue/fine-grained-locks-build-1001631

Avoid workspace-wide locks when building.