Initial commit of the Move Class refactoring.

You can either move a single class from a file with multiple definitions to its
own file, or move the complete file. The package declaration will be updated,
and the imports/references to the moved class are adjusted in the project. The
refactoring is also involved when a source file is moved from the package
explorer.

Of course Move Class also works on Traits and Objects.

Some restrictions: it works only on Scala sources, and not across multiple
projects. Also, visibility issues that might arise are completely ignored.

I also implemented Iulian's suggestion to filter the files in the project and to
only create an index for those that contain the name of the class we move or
rename. This speeds up renaming and moving considerably.

Apart from the refactoring changes, I also had to change how existing
compilation units are reconciled: When moving a compilation unit, the
presentation compiler is reset and reconciles all the managed units. At this
point, the moved compilation unit doesn't exist anymore, resulting in an
Exception later on because the resource can't be found anymore. So now we only
reconcile units that exist.

Fixes #1000422, #1000836, #1000842
Merge pull request #65 from scala-ide/issue/move-class-refactoring-1000422

Issue/move class refactoring 1000422
Adapt import to HasLogger trait.
Fixing race conditions in the interpreter wrappers.

Completely replaced EclipseRepl to clearly define its behavior and isolate all its actions inside its Actor. Found one race condition in ReplConsoleView, and also updated it and RunSelectionAction to use the new EclipseRepl API.
Add unit tests for EclipseRepl.

These are not run during the build yet: see comments in EclipseReplTest.
Changes inspired by Mirco's review.

The idea of 'recovery' was flawed, so now the Actor gets terminated on any
Exception. A few Client callbacks were added so the client doesn't have to
do as much work keeping track of the Actor state. Settings are initialized
from the project again to avoid bug in Settings.copy. REPL view can be used
with pure Java projects. REPL view requires project.isOpen.
Merge branch 'interpreter-EclipseRepl-rewritten-1000883'
Bumped SBT version number.
Updated the director script with an option to install from an update site on the file system.
Use File.pathSeparator when building the pluginsDir setting, to be platform independent. Fixes #1000901.
Use the refactoring's progress monitor when run as move participant.

When the Move Class refactoring participant is used in Eclipse's generic
Move Resource refactoring that has its own wizard (in contrast to moving
with drag and drop), we don't run the participant in a separate dialog.
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