Don't add local suffix (one space character) for field completions

Correctly deal with private local fields backing up a val/var. The
presentation compiler always returns the `val` backing up a val/var, for
reasons of uniformity (getters won't work everywhere, because local variables
or private fields don't have a getter). However, the
proper way to look at such fields is to look for their getter (who
has the correct name, accessibility flags, etc).

Fixes #1001973
Add synchronisation around map `getOrElse`.

Needed for proper visibility, in case this code
is called on different threads.
(cherry picked from commit 6181d7f57da6c28cc6f6ef0df873a2f7a960ba73)
Merge pull request #610 from dragos/issue/flaky-completion-relevance-test-1001973

Don't add local suffix (one space character) for field completions
Merge pull request #612 from dragos/issue/add-sync-caching-jars

Add synchronisation around map `getOrElse`.
Adds decorator extension point to change icons for Scala files

Scala files which are not on the classpath of a project get displayed
with an icon that is made for Java files. This commit replaces the Java
icon with a different one by using a decorator. Only the large icon is
replaced - smaller ones in the corners are not affected.

The decorator is enabled by default and can be disabled in
"Preferences/General/Appearance/Label Decorations/Scala Decorations"

This change only affects Scala files that are not on the classpath
because internally they are represented with a different object
compared to all other Scala files.

Fixes #1001975
Merge pull request #616 from sschaef/t1001975-enable-icon-for-files-not-on-classpath

Adds decorator extension point to change icons for Scala files
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.