Add tasksupport as a configurable field in parallel collections.

This required a bit of refactoring in the tasks objects and implementations
of various operations. Combiners now hold a reference to a tasksupport
object and pass it on to their result if `resultWithTaskSupport` is called.

Additionally, several bugs that have to do with CanBuildFrom and combiner
resolution have been fixed.
Change time constants in test to avoid failures.
Merge remote-tracking branches 'namin/add-test-for-finitary-error', 'namin/add-test-for-parent-inherited-twice-error', 'namin/add-test-for-constructor-prefix-error', 'namin/add-tests-for-qualifying-class-error', 'namin/add-test-for-abstraction-from-volatile-type-error' and 'axel22/issue/5293' into develop
One more to derive trees.

ClassDefs, CaseDefs, and LabelDefs.  Dotting eyes,
crossing tees.  Point of diminishing returns is reached,
declare victory and withdraw.
Merge remote-tracking branch 'adriaanm/ticket/errortests'
Make partest not fail over code.jar's placement.
Moved and edited tests.

Remove obsolete, move passing pending -> files, update
those-kinds-are-high with some new info, added a couple
new ones to pending.
update api docs for @elidable to match the behaviour more closely.
Fix to nightly build.

You see shelling to other ant builds doesn't let us declare dependencies
on the primary build, so to ensure all tasks are run when needed,
and that we don't slow everyone down with javadocs, we wind up
with a bit of spaghetti.
Merge pull request #234 from jsuereth/fix-annoying-task-dependency

Fix to nightly build.
Followed up on two aged todos.

  // to avoid infinite expansions. todo: not sure whether this is needed

Survey says: if it's needed, more evidence is needed.

  // TODO: this should be simplified; in the stable case, one can probably
  // just use an Ident to the tree.symbol. Why an existential in the non-stable case?

My answers are in comment form herein.  I simplified as much
as I was able.
Merge remote-tracking branch 'szabolcsberecz/SI-5215' into develop
Fleshed out the @elidable documentation.
-Xplugin value passed by the Eclipse IDE are incorrectly parsed when it
contains whitespaces.

Assume -Xplugin is given the value

  C:\Programs Files\plugins\Aplugin.jar C:\Programs Files\plugins\Bplugin.jar

Calling ``tryToSetFromPropertyValue`` with the above value will always result
in a total mess, no matter what, because it will split the string at
whitespaces.

The proposed solution is to change the implementation of
``tryToSetFromPropertyValue`` to use `,` (comma) as the splitting character

Further, I'm quite convinced that the current implementation of
``MultiStringSetting.tryToSetFromPropertyValue`` has never worked, that is why I
did not create an overload of ``tryToSetFromPropertyValue`` where the splitting
character (or string) can be passed as argument.

There is also an Eclipse Scala IDE associated to this issue:

  http://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1000917
Better fix for memory leaks in the presentation compiler. Switched to perRunCaches and call clearAll from the presentation compiler
Improvement to API docs: GenTraversableLike and List. Fixes SI-5522.
Added updated ForkJoinPool, w/ necessary updates to Scala Actors.

This commit includes Doug Lea's updates to ForkJoinPool, as of January
25th, 2012. Details of the changes and performance improvements
available at: http://markmail.org/message/323vxzn6irkk5yrg.
The ForkJoinPool used in this commit comes from the most recent JSR166y.

Additionally, also included are minimal changes to parts of the Scala
Actors library which interface with the ForkJoinPool, as the
ForkJoinPool's interface has changed (prior to the release of Java 7)
since we last updated it for the Scala 2.8 release.

Of note- this is part of the planned overhaul of scala.concurrent,
and corresponds to ticket SI-5523.

For testing this was built on JDK 1.6, and passes all tests on both
JDK 1.5 and 1.6.

A new forkjoin.jar is necessary prior to applying these changes.
Using this source, the new jar can be built by running:

    ant newforkjoin forkjoin.done

This creates a new forkjoin.jar in build/libs/. It must replace
lib/forkjoin.jar.
Mainstreaming phase awareness.

As I peer into various longstanding crashes involving specialization,
mixin composition, and super calls, I find a very common reason for
logic to go wrong is ignoring or misusing atPhase. This is hardly
surprising given how much of a secret black art the whole process of
atPhase-ing is. I predict with some confidence that at least half the
calls to atPhase in the compiler are at best unnecessary and more likely
wrong; similarly, we are missing at least as many calls in other places.

Herein we find the following:

1) log messages now include not only the current "at" phase, which
in isolation was very confusing because it means what is logged is
dependent on the arbitrary jumps performed by atPhase, but the entire
"phase stack", anchored by the "global phase".

The leftmost phase is the global phase, the one set in Global which
proceeds in a predictable fashion from parser to terminal. That's the
one we usually mean when we talk about during which phase something
happens. The others (prefixed with an arrow) are calls to atPhase which
have not yet returned.

  // example, assuming we've given -Ylog:expl
  scala> atPhase(currentRun.explicitouterPhase)(log("hi mom"))
  [log terminal(->typer ->explicitouter)] hi mom

2) A message will be logged if either the globalPhase matches,
or the current "at" phase does.  So -Ylog:erasure will log all the
messages from the phase we think of as erasure, and also all those
from any phase run inside of atPhase(erasurePhase) { ... }
(except for times when that block uses atPhase to alter the
phase yet again - it only looks at the top of the atPhase stack.)

  // example
  % scalac -Ydebug -Ylog:refchecks foo.scala

  [log refchecks] overriding-pairs? method size in trait TraversableOnce ...
  [log mixin(->refchecks)] rebindsuper trait GenTraversable <none> <notype> false

3) A number of debug/power oriented functions.  All of these
limit their results to phase transitions during which some change took
place, as measured by the result of `op`, compared with ==.

  def afterEachPhase[T](op: => T): List[(Phase, T)]
  def changesAfterEachPhase[T](op: => List[T]): List[ChangeAfterPhase[T]]

  def logAfterEveryPhase[T](msg: String)(op: => T)
  def describeAfterEachPhase[T](op: => T): List[String]
  def describeAfterEveryPhase[T](op: => T): String
  def printAfterEachPhase[T](op: => T): Unit

Some examples:

  scala> printAfterEachPhase(ListClass.info.members.size)
    [after  1/parser      ] 219
    [after 11/tailcalls   ] 220
    [after 12/specialize  ] 322
    [after 14/erasure     ] 361
    [after 18/flatten     ] 357

  scala> printAfterEachPhase(termMember(PredefModule, "implicitly").defString)
    [after  1/parser      ] def implicitly[T](implicit e: T): T
    [after 10/uncurry     ] def implicitly[T](e: T): T
    [after 14/erasure     ] def implicitly(e: Object): Object

Try this at home:

  scala> changesAfterEachPhase(ListClass.info.nonPrivateMembers map (_.defString)) foreach println
Merge remote-tracking branches 'heathermiller/issue/5522' and 'heathermiller/issue/5523' into develop
New forkjoin jar as described in 76e9da2ca4 .