Added SCALA_LIBRARY_VERSION for trunk.
Switch to the new sbt.full.library version scheme.
Fixed bundle version inconsistency.
Deleted the lib/miglayout.jar binary and updated the scala-ide.sdt.core POM to
copy the miglayout dependencies in the lib/ folder. This has a consequence in
our project's setup (yes, the dev doc has been updated), which is: you need to
compile the project from the command line *before* starting to work on the
Scala IDE sources in Eclipse.  That because the project's dependencies are
copied in the lib folder when maven runs the build of the
org.scala-ide.sdt.core project.
Improved logging infrastructure and plugged Log4J in the scala-ide.sdt.core
project.

We used to have too many alternatives to create log items (Eclipse Log
framework, our ad-hoc naive internal Logger and println statements originating
from scalac). In short, we did not have an ideal logging infrastructure.

Now, I plugged Log4J as the backend logger (I'll refer to it as the "default
logger" in the rest of this commit message), which replaces our naive ad-hoc
Logger. Further, all log events occurring in the Eclipse Log Framework are now
*forwarded* to the default logger. Also, the Standard Output and Standard Error
are *redirected* to the default logger.  The  goal is to have a single place
to consult the log, and that is now the *scala-ide.log* file that is produced
by the default logger, located in

  ${workspace}/.metadata/.plugin/org.scala-ide.sdt.core/

It's easy to consult the log from within Eclipse, just open the Eclipse
Preferences, then Scala > Logging, and there is a link to open the
*scala-ide.log* file in the editor (though, mind that it is not automatically
refreshed while it's open).

From the same preference's page, you can also control the amount of produced
log, i.e., you can set the log level that better suits you (the default level
is WARNING).  If needed, you can also enable a console appender to print all
produced log items in the console (this is quite handy when doing development
on the Scala IDE sources).

To get a handle on the loggers you simply need to mix-in the HasLogger trait,
which contains a reference to both the default logger and the Eclipse Log. You
may wonder why we have two loggers. The reason is simple, if you want to
communicate a message to the user, you should use the Eclipse Log. This becayse
messages sent to the Eclipse Log are shown in the Eclipse Log View (remember
that all messages sent to the Eclipse Log are also forwarded to the default
logger, so you don't need to log the same message twice). In all other cases,
you should use th default logger.

Finally, I removed the "plugininfo" option, which it was used to enable debug
information in the ScalaIndexBuilder. As a matter of fact, the amount of logged
information can now be easily controlled through Log Levels.

One element I'm not happy with is that I plugged Log4J within the
scala-ide.sdt.core project and not as an external plug-in. I've tried to do so
but failed due to my lack of understanding of OSGi.  This is something that I
believe we should do at some point (maybe someone can help with this?!).

Fixes #1000880.
Merge branch 'master', remote-tracking branch 'origin'
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.