Slightly increased VM heap space

This was done to prevent ``java.lang.OutOfMemoryError: Java heap space`` to be
thrown during project's build.
Fix #1001233 - Graceful termination of debug sessions

Major refactoring of actor code in debugger

Extracted a common superclass (``BaseDebuggerActor``) for all actors defined in
the debugger module. This avoids duplication and makes sure that actors
terminates consistently. This base class for actors provides a number of
interesting functionalities:

* Automatic logging of all messages processed by the actor. This can be quite
useful when debugging. However, this functionality is currently commented
because it generates a lot of noise. Before enabling it, we need to add a TRACE
log level in the logger (I'll open a ticket for this).

* Stackable behaviors. By calling `become/unbecome` an actor can easily
modify the shape of messages that it processes.

* Cleaner actor's life-cylce. Basically, when starting an actor, `postStart`
hook is guaranteed to be called before the processing of any message. Then, the
actor will process messages accordingly to its `behavior` implementation.  If
an `Exit` or `PoisonPill` message is processed by `this` actor, the actor is
guaranteed to execute `preExit` before terminating.

Last, I have also added a number of FIXMEs for some problematic code that could
cause the debug session to freeze. I'll be opening tickets for each one of
these issues, so that we don't forget to fix them by the final V2.1 release
(Re #1001307, Re #1001308, Re #1001310, Re #1001311).
Refactoring of ``ScalaStep`` hierarchy.

Extracted a class that encapsulates the shared debugger stepping behavior.
Merge pull request #221 from dotta/issue/io-exception-from-vm-1001233

issue/io-exception-from-vm-1001233

Graceful termination of debug sessions
Throw an exception if the launcher fails.

The `MainMethodVerifier` may stop the Scala launcher if there is no main type,
or the project has errors. The Eclipse API requires that we throw `CoreException`,
but we used to fail silently (leading to the debug tests hanging indefinitely).
Simplify the ScalaStep hierarchy

I noticed that each type of Scala step (over, into, return) induced some unnecessary code
ceremony: a private empty class extending a class having all the functionality. Moreover,
each private class had to prevent others from instantiating it, by making the constructor
private. Seemed that it was working more like a *value* member than a class.

Since all steps work the same way, by sending two messages to an actor, I turned the `Base` class
into the implementation class used by all kinds of steps.
Merge pull request #226 from dragos/refactor/simplify-step-hierarchy

Simplify the ScalaStep hierarchy
Moved out askType from inside `ask`.

The presentation compiler is not designed to handle a call to `askType` inside an
ask. The `ask` is run during type-checking, and `askType` will usually trigger a complete
re-type-check of the (possible same) file. This may lead to spurious errors and bring
the compiler in a bad state.
Re-format.
Merge pull request #225 from dragos/issue/no-askType-inside-ask-in-occurrences

Moved out askType from inside `ask`. 
Filter out step into forwarder and default getter methods.

A general reorganization of step filters was necessary:

- made it a class instead of an object
- split functionality between the filter class and a method classifier
- split tests in unit tests (using the method classifier) and integration tests (testing the step-into
  inside a debugger instance)

A separate commit makes the Scala launch delegate behave according to the spec, throwing
`CoreException` on failure. Failure to do so was making tests hang indefinitely when a debug-test 
project had errors, and therefore could not be launched.

Fixed #1001288.
Correctly shutdown actor after tests

Added an @After method to shutdown the actors created during
the debugger unit tests.

Fix #1001322
Replaced actor pulling by pushing

The states are stored in the class, the actor uses methods to request state changes.

Added regression tests.

Fix #1001308
Fixed style according to review
Merge pull request #227 from skyluc/issue/kill-actors-1001322

Correctly shutdown actor after tests
Merge pull request #223 from skyluc/issue/debugger-freeze-1001308

Replaced actor pulling by pushing
Merge pull request #224 from dragos/issue/more-step-filters-1001288

Filter out step into forwarder and default getter methods.
Fixed #1001327 - Infinite "Update Occurrences" error dialog

Basically, calling `global.loadedType` could throw an exception, and any
unhandled exception occurring in an Eclipse thread result in an error dialog
being displayed to the user. This is extremely annoying when the exception
keeps occurring, as it prevents typing in the editor!

The fix I implemented is to change the return type of the following
`ScalaPresentationCompiler`'s methods: `body`, `loadedType` and `withStructure`
to return a `Either[T, Throwable], and let the caller decide how they want to
handle the error.

Which brings me to the actual implemented fix. As you'll see in the committed
code, I'm simply ignoring any exception that may have occurred in the
Presentation Compiler side, and simply map the exception into a meaningful
NullObject (e.g., ``EmptyTree``).
It is worth noting that the exception is simply swallowed, i.e., it's not even
logged! The reason why I do so is to avoid generating noise in the logger for
something that is supposed to automagically heal itself (and, if it can't heal,
it usually means that the presentation compiler is in a bad state, and the
reason for this should be found elsewhere).

One last bit of information, this ticket is somewhat related to commit
15b66bbc0e8010275089ee967c128fa98e135be8. In the mentioned commit there has
been a refactoring for disallowing `loadedType` calls inside an `askOption` (as
this can bring the presentation compiler in a bad state). The side-effect of
running `loadedType` *outside* of `askOption` is that exception thrown inside
`loadedType` were hence left unhandled, and this resulted in the infinite
"Update Occurrences" error dialog to be displayed to the user.
Use the proper platform methods in the Scala launcher

This is a small refactoring that improves a bit the Scala launcher:

* the existence of the main class is checked in `finalLaunchCheck`, instead of inside `launch`
* compilation errors are done through markers, and integrates with the platform error message. The check is
  also done during `finalLaunchCheck` and now prompts the user if any required project has compilation errors
  before launching.

Fixed #100740, possibly others.
Merge pull request #228 from dotta/issue/infinite-update-occurrences-error-dialog-1001327

Fixed #1001327 - Infinite "Update Occurrences" error dialog