Activate CommentAutoEditStrategyTest
Correct auto indentation after line breaks in multi line comments

There was a bug with auto indentation for lines starting with spaces,
because all spaces in a line are counted instead of only the ones
before the caret position (the position where the line break happens).

Fixes #1001514
Corrects behavior for auto closing multi line comments

The new behavior matches the behavior of the Java Editor and is also
more useful because if one wants to place a multi line comment before
regular source code, one should do this in the line before and not in
the same one.

Fixes #1001516
Solves bug in CommentAutoIndentStrategy

Because of the new introduced Scaladoc code blocks the end of open
Scaladoc comments was not correctly detected anymore. Before, there was
looked if the actual partition reaches the end of the file, now it is
looked if the last partition of the file is a Scaladoc partition. This
makes a difference because Scaladoc comments are divided into multiple
parts when they contain code blocks, thus the part containing the start
of the Scaladoc section is not the same as the part containing the end
of the Scaladoc section.

Fix #1001463
Correct behavior of multi line comments before string literals

This is not a full fix for the problem that multi line comments are not
automatically closed when they are followed by a string containing the
*/ sign. It is difficult to completely solve this problem because
whenever one opens a multi line comment with /* the rest of the document
does no longer contain any partitions because the comment spans the
complete content. Thus, it is not possible anymore to detect if the
closing sign */ is located inside of strings or not.

The behavior introduced solves the problem as good as possible. What it
does is it looks if the line containing a */ sign contains a quotation
mark. If this is the case it is assumed that the ending is located
inside of a string literal, thus the multi line comment is closed.

This fix doesn't work if the */ sign is located inside of multi line
string literals or if the string literals aren't even closed but it
helps at least partially.

Fixes #1001515
Add option to preferences to activate auto closing multi line comments
attribute merges to the branch author, NOT the merger
Use Scala specific task markers.

Don't use Java task markers for Scala sources, as the Java builder
removes them all on "full build", which is what we trigger from the
Sbt build manager if:

* Java sources need recompilation
* resources (non-source files) exist on the source path (so they are 
  copied to the output folder)

This commit adds a Scala specific marker type (subtype of the Java one)
that preserves all functionality, but is only handled by our code.

Fixed #1001401, #1000975.
Modified the script to pick up commits that were NOT introduced through a merge.
(since we do many backports this way)

Cherry-picks are attributed to the picker, though, NOT to the original author.
Organize imports.
Merge pull request #330 from dragos/isssue/tasks-disappear-1001401

Use Scala specific task markers.
Do not force default location of -XpluginsDir in Scala Compiler Preferences

Trying to force the default location to the plugins directory containing the
continuations.jar plugin turned out to be a very bad idea (this was done as
part of commit SHA-cbfd82d874f998b7726fec895ad4d83194ad1e5b).

The issue is that the default location where the continuations.jar is stored
changes *each time a user updates the Scala IDE* and, when updating, the
*former location is deleted*. The net effect of this is that after upgrading,
all projects using the continuations plugin would report the following error

	`bad option: -P:continuations:enable` is reported

Simply because the continuations.jar can no longer be located.

The fix is to somewhat restore the former implementation wrt how we handle the
`-Xpluginsdir` compiler setting. Basically, the solution consists in not
showing the default value of `-Xpluginsdir` to the user in the Preferences
dialog, and pass this default to the different compiler instance we create
unless the user specifices a different location (in which case, we do use the
location provided by the user).

There is one more catch due to the current way `ScalaProject.scalacArguments`
is implemented (the method is used to pass the compiler arguments to the Sbt
builder). In short, the returned arguments are only the ones forces by the user
via the Preference dialog. Since the `-Xpluginsdir` default directory is
**not** shown in the Preference dialog, the Sbt builder would fail to compiler
projects with continuations enabled because it wouldn't know where to look for
the continuations.jar. Hence, I had to add some ad-hoc code to handle this
correctly in `ScalaProject.scalacArguments`.

This whole fix is far from ideal, but I want to keep the changeset as small as
possible to avoid regressions, since this commit should be included in the
upcoming 3.0.0 release.

By the way, all existing projects that were affected by the error should
restore the defaults (Preferences > Scala > Compiler and hit the Restore
Defaults button).

Fixes #1001030, #1000700
Testing presentation compiler when project depends on continuations.jar

Added a couple of tests for making sure that the build compiler and the
presentation compiler behave the same when compiling projects that depend on
the continuations plugin.
Merge pull request #332 from dotta/issue/cannot-enable-continuations-plugin-1001030

Issue/cannot enable continuations plugin 1001030
Make the script more portable
Mimick the reStructuredText format of the previous Changelog
Added debug mode as an option
Corrected the portability issue
Thanks Toni (and the Macbook in the conf' room)
Minor correcitons, as per @dragos comments
Merge pull request #315 from sschaef/issue/comment-auto-edit-improvements

Issue/comment auto edit improvements
Add semantic highlighting for singleton types

Fixes #1001555