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
Merge remote-tracking branch 'upstream/release/scala-ide-3.0.x' into release/scala-ide-3.0.x-juno