Logging more info about settings initialization in ScalaPlugin. No review.
Override default when an explicit value is provided for `-XpluginsDir`.

In the IDE, for convenience we use to se the value of `-XpluginDir` to the
default location in the distribution that contains the continuations.jar
plugin.  This is convenient because users need only to pass
`-P:continuations:enable` to use the continuations plugin.

If in the IDE an explicit value is provided for `-XpluginsDir`, then we simply
concatenate the user's provided plugins' directory to the default one.  This
generally works fine and allows users to keep using the continuations plugin
without having to copy the continuations.jar in the provided user's plugin
directory.

However, by passing the additional parameter -Xplugin
${path-to-continuations-plugin}, the compiler is unable to load the
continuations.jar. The reason is that there is ambiguity. `-XpluginsDir`
instructs the compiler to load all plugins available in the passed
directory(ies) and, as we said in the first paragraph, that means that the
continuations' plugin gets always loaded. Now, when also `-Xplugin
${path-to-continuations-plugin}` the Scala compiler seems to get lost because
it sees the continuations.jar twice, and it looks like it decided to simply not
load it. Hence, the compiler will complain that the continuations plugin isn't
enabled. That looks like a bug, and a ticket in the Scala compiler JIRA has
been created for this: https://issues.scala-lang.org/browse/SI-5491.

But in consideration of what has been said, I believe that we should not try to
always set `-XpluginsDir` to point to the default location in the distribution.
If the user decides that it should point to some other place, then provided
location should be used. That actually matches the Scala compiler's behavior.

Fix #1000908.
For no apparent reason, using `ScalaPlugin.defaultScalaSettings` is not the
same as `new Settings` in `SettingsCleanup` class, and I honestly really can't
see a reason (if anyone has an idea, please don't be shy).

The issue with using `ScalaPlugin.defaultScalaSettings` is that SBT may fail
compiling sources that depends on the continuations plugin. For instance,
assume you have a `plugins` folder (located in ${PATH_TO_PLUGINS_DIR})
containing the continuations.jar plugin, and in the project's settings the
following options are passed:

  -P:continuations:enable
  -Xplugin ${PATH_TO_PLUGINS_DIR}/continuations.jar
  -XpluginsDir ${PATH_TO_PLUGINS_DIR}

The SBT compiler will fail to compile the sources because it can't locate the
continuations plugin.  While, when using `new Settings`, it all works fine.

I've add a FIXME note to remind us of the problem.
After opening a file, ask the user to refresh the file every time it changes.
Made sure that logger is initialized before being used.

When starting the IDE, you may have noticed the following message in the
console:

  log4j:WARN No appenders could be found for logger (ScalaPlugin).
  log4j:WARN Please initialize the log4j system properly.
  log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

Which was caused by some eager fields in ScalaPlugin. Since the logger is
initialized when calling `ScalaPlugin.start`, eager fields in `ScalaPlugin`
should not try to access the logger or the above warning message is produced.

To fix the issue, the eager fields have been transformed into lazy ones.
Temporarily remove the SysOut/Err redirects while attaching the Console Appender to the set of log appenders.

It has been noticed that enabling the console appender was generating a stackoverflow exception. The reason
was that the standard output/error is being redirected to the logger, and attaching a console appender was
causing a recursion.

To avoid the recursion it is sufficient to disable the standard output/error redirects while attaching the
console appender.

Fix #1000903.

Integrated comments from pull #71.
When running in headless mode, set the default log level to DEBUG and always
enable the console appender.
Added bash script to update the Scala version in an existing Eclipse installation. Use with care.
Moved from scala-tools.org to Sonatype's repository
Fixed a long-standing bug in the JavaScalaMapper, by adding an askOption when looking at TypeTree.symbol.

Also removed a bunch of useless logging.
Use correct version of Equinox Hook for Indigo
Added a test for memory leaks, using the scalac sources.
Incorporated review comments.
Passing to -Xplugin a path containing whitespaces is finally parsed correctly.

Up until now, passing to -Xplugin a path containing whitespaces resulted in
*no* plugin being loaded. That because
``MultiStringSetting#tryToSetFromPropertyValue`` was splitting the passed value
at whitespace occurrences, which was of course resulting in a mess.

The pull request https://github.com/scala/scala/pull/235 in the Scala compiler
has fixed this issue (patch available in both 2.10 and 2.9.2). In short, now
commas (``,``) are used to split -Xplugin value (when more than one plugin is
passed to it). Some adaptation on our side was also needed for correctly
handling commas as the splitting character.

This commit also fix a issue with the way we used to hande -Xpluginsdir value.
Read the big comment in ScalaPlugin.defaultScalaSettings for more information
about this.

As a side note, enabling continuations should now work as described in
http://scala-ide.org/docs/tutorials/continuations-plugin/index.html.

Fixes #1000917.

Integrated @skyluc code review (pull #75) and added a couple of new tests to
check that compilation of a source requiring the continuations plugin enabled,
works as expected.
Added 'normalize' when mapping a type that might be an alias.
Don't print empty lines when redirecting stdout or stderr through the logger.
Make the R script work with https, so one can point it directly to the Jenkins logs and get
a plot of the latest run.
Fixed 1000893. Added an option to stop building downstream projects
if a project has compilation errors.(cherry picked from commit 0b3c20c0ad0cc1bc731f20f065c7b5dcd1b4edc1)

Conflicts:

	org.scala-ide.sdt.core/src/scala/tools/eclipse/ScalaBuilder.scala
Pass upstream projects API to the Sbt builder.
Retrieve upstream analysis recursively, on all dependent projects.
Moved the analysis store to the build manager level, instead of the compile run.
Fixed transitive and direct dependencies for project builders.