Refactoring in `ScalaClasspathContainers`

Pushed up `libraryEntries` method so that it can be used by the two subclasses
of `ScalaClasspathContainerInitializer`
Add an option to show API diffs when building

The incremental compiler can print diffs that explain
why additional files need recompilation. This commit adds
the diffutil.jar and a user-level option.

Fixed #1001952
Removed special support for Scala continuations

The Scala IDE used to package the continuations plug-in to match the Scala
distribution.  While this conveniency was appreciated by the few using
continuations in their projects, it imposed a technical debt on the Scala IDE
codebase (have a look at how the compiler `Settings` used to be instantiated).

Recently, the continuations plug-in has been refactored and splitted into two
separate JARs (a compiler plug-in, and a library). After this modularization,
the Scala IDE codebase could no longer be compiled inside Eclipse because the
continuations library isn't included in the project's classpath. Of course, we
could implement a workaround to restore the functionality, but it just doesn't
seem worth the time, considering the Scala Team has deprecated the
continuations plug-in and will effectively drop supporting it the moment 2.12
is released.  Hence, the decision of dropping the out-of-the-box support in the
Scala IDE.

From now on, if you want to use continutions in a project, you will have to
provide the location of the continuations JAR via the -Xplugins setting.

Finally, a couple of tests exercicing the behavior of both the presentation
compiler and the build compiler when compiling a sourcefile that requires the
continuations plug-in are now executed only for Scala 2.11 or later. This is
needed because the continuations.jar is no longer loaded when starting the
compiler inside Eclipse, and that turns out to affect semantic of programs
using continuations in Scala 2.10, because the compiler does no longer report
an error if a source file (requiring continuations) is compiled without passing
the flag to enable the plugin. Why? Because up until Scala 2.10 the compilation
error is reported by the continuations.jar (!!). Of course, that error cannot
be reported if the continuations.jar isn't available anymore (which is the
whole point of this commit).  The behavior with Scala 2.11 is different because
the continuations library has been moved out of the scala library (see
https://github.com/scala/scala/commit/858a5d513779f4af6f12c0a530bdeceb7a7fd4d9),
and hence a compilation error is reported whenever a source is compiled without
the continuations library in the classpath. That explains why the tests are now
only executed on 2.11+.

This commit undos all changes related to supporting continuations made by
@adriaanm in https://github.com/scala-ide/scala-ide/pull/604

Fix #1002012
Fix #1002011
Merge pull request #617 from dotta/issue/remove-continuations-plugin-support

Issue/remove continuations plugin support
Merge pull request #615 from dragos/api-diff

Add an option to show API diffs when building
Fixed NPE on quick assist proposals

In the former implementation, the implicit conversion `Predef.refArrayOps`
could be applied on a `null` value, because `null` was returned if
`corrections.isEmpty` was true, leading to a NPE.

Fix #1002014
Merge pull request #618 from dotta/issue/npe-on-quickassist-1002014

Fixed NPE on quick assist proposals
Using the enclosed type to fix completion and imports for inner classes.

Make sure that the enclosing object is passed to the indexer also for modules.

Fix #1002002
Merge pull request #607 from tbje/fix-inner-type-completion-#1002002

Using the enclosed type to fix completion and imports for inner classes.
Removed FIXME in `ScalaSourceFile` (Refactoring)

I thought the only way to get rid of the FIXME was to introduce a
`NullResponse`, which is why I believed it was a good idea to extract a pure
interface from `Response`. As the code demonstrates, it turns out I was wrong in
believing I needed a `NullResponse`.

As a side note, while I think it may still be a good idea to turn `Response`
into a pure interface, I realistically don't see a use-case.  Further, it turns
out that implementing the semantic of a `NullReponse` wouldn't be
straightforward, because the current implementation of `Response` is somewhat
incorrect in my opinion. The issue I see is that a `Response`'s answer shouldn't
change after it is `set`, however this is not enforced in the current
implementation (e.g., one could call `set` and aferward `raise`, and the answer
to `get` would be different depending if it's executed before or after the call
to `raise` - I would consider this a bug). Hence, it currently doesn't make much
sense to turn `Response` into a pure interface.
Do not use system properties to configure incremental compiler.

Since sbt 0.13.0 we have an official mechanism for configuring
incremental compiler: IncOptions class. The IDE has been partially migrated
to use that mechanism but one use of old mechanism (that relies on JVM
system properties) was left intact. The `incDebugProp` was used to enable
debugging of relations.

We switch to `IncOptions.relationsDebug` to control debugging of relations
and get rid of manipulating system properties.

This change makes IDE compatible with all sbt 0.13.x versions (including
0.13.2-M1).
Merge pull request #620 from gkossakowski/incDebug-property

Do not use system properties to configure incremental compiler.
Attempt to shut down any PC that just threw.

Alleviates the symptoms of error sin the class of #1002016.
Clean up .classpath files

Some .classpath files still contain references to SCALA_CONTAINER and
SCALA_COMPILER_CONTAINER which are not needed anymore. Furthermore
sdt.core explicitly references JavaSE-1.6 as its runtime environment
which shoudn't be included either because this doesn't allow a JRE
independent build.
SI-8151 Prepare for removal of -Yself-in-annots

Upstream, Scala will remove the `selfsym` field from `AnnotatedType`.

This commit removes its uses in Scala IDE:

  1. In debug printing code
  2. In a commented-out pattern match
Merge pull request #627 from retronym/topic/annotated-no-self-sym

SI-8151 Prepare for removal of -Yself-in-annots
Merge pull request #619 from dotta/wip/remove-fixme-in-scala-source-file

Removed FIXME in `ScalaSourceFile` (Refactoring)
Reformat old code.
Catch `JavaModelException` if a resource isn't there.

This code might be called for elements that were deleted. The original
code tried to be robust, but failed to treat checked exception `JavaModelException`.
Use the presentation compiler to check for existing types.

The original code relied on Java search, that can be slow and imprecise
for Scala types.