SI-6221 inference with Function1 subtypes.

There appears to be no upper bound on the number of places
we have to remove calls to typeSymbol and introduce calls to
baseType. This one was type inference for function parameter
types: worked when expected type was A => B, but not if there
was an implicit conversion from A => B to the expected type.
No more duplication in maven-deploy.xml.

I just couldn't stand the incredible mess in there anymore. More cleanup to come.
For now, suffice it to say you need only add one line per new module.
Spin off src/library/scala/xml to src/xml/scala/xml.

Summary:
  - Remove the last vestiges of xml from Predef and Contexts.
  - Change build to compile scala.xml to scala-xml.jar.
  - Deploy scala-xml module to maven.
  - Update partest accordingly.

Note:
An older compiler cannot use the new standard library to
compile projects that use XML. Thus, skipping locker will
break the build until we use 2.11.0-M4 for STARR.

In the future build process, where we drop locker,
we would have to release a milestone that supports the old
and the new approach to xml. As soon as we'd be using that
new milestone for starr, we could drop support for the old approach.
Spin off parser combinators to scala-parser-combinators.jar.
Unfork jline: use vanilla jline 2.11 as a dependency.

Notes:
  - no longer specifying terminal by class name in scripts (using 'unix')
  - jline doesn't need a separate jansi dependency;
    it includes its own version according to:
    http://mvnrepository.com/artifact/jline/jline/2.11
Add meta-information for dbuild.

The next version of [dbuild](http://typesafehub.github.io/distributed-build/0.5.3/index.html)
will parse `dbuild-meta.json` to determine which jars are produced by a Scala build.

This way we can modularize without changing dbuild itself.

Yes, I know `dbuild-meta.json` should be generated during the build.
However, given the state of our build.xml, I think this is pointless.

My goal is to generate build.xml, dbuild-meta.json and Eclipse projects
from a higher-level description of our build. Baby steps...

Including improvements by @cunei:
  - Removing outdated field "uri" from ExtractedBuildMeta
  - Changed "partest" to "scala-partest" (the actual jar name)
Updated eclipse project files.

Set everything up so that soon-to-be independent modules are
compiled with the Eclipse plugin's compiler & library (2.11.0-M3 currently).

Most projects still compile with 2.11.0-M3, but
partest will need a nightly build of 2.11.
SI-7614 Minimize the times of evaluation f in TraversableOnce.maxBy/minBy.

In the previous implementation, maxBy/minBy will evaluate most of its elements
with f twice to get the ordering. That results (2n - 2) evaluations of f.

I save both the element and result of evaluation to a tuple so that it doesn't
need to re-evaluate f on next comparison. Thus only n evaluations of f, that is
the optimal.

Note that the original implementation always returns the first matched if more
than one element evaluated to same largest/smallest value of f. I document
this behavior explicitly in this commit as well.
Merge pull request #2688 from yllan/SI-7614

SI-7614 Minimize the times of evaluation f in TraversableOnce.maxBy/minBy
Merge pull request #2650 from paulp/issue/6221

SI-6221 inference with Function1 subtypes.
scaladoc needs xml and parser-combinators

Concretely, update scala-compiler's pom
to list scala-xml and scala-parser-combinators
on behalf of scaladoc.

NOTE: when spinning off scaladoc, move dependencies to its own pom
Merge pull request #2704 from adriaanm/modularize

Separate jars for XML, Parser Combinators. Use released JLine.
SI-7592 Remove scala.tools.nsc.util.MultiHashMap