Scaladoc: Inherited templates in diagrams

Related to SI-3314, where we started showing inherited templates
that were normally not documented. This patch corrects a problem
in parentTypes that was preventing inherited templates from being
displayed in diagrams.

Also renamed:
PackageDiagram => ContentDiagram
ClassDiagram => InheritanceDiagram
which should have been done much earlier
SI-5965 Scaladoc crash

This bug was fixed by the model upgrade in c11427c1. Test case confirmation.
SI-5558 Package object members indexing

This bug was fixed by the model upgrade in c11427c1. Test case confirmation.
SI-4324 Scaladoc case class argument currying

case class C(i: Int)(b: Boolean) would appear uncurried in scaladoc:
case class C(i: Int, b: Boolean)
Scaladoc: workaround for untypical Map usecases

SI-3448 partial fix:

This enables a workaround for the fact that Map takes two type params
while $Coll takes only one. But it doesn't fix the problem though,
as there's one more piece missing from the puzzle - we need to adjust
the `Coll`s in {immutable, mutable, concurrent}.Map to something that
makes sense for the usecase. And that's not possible. But I'm
committing this nevertheless, maybe other projects can benefit from it.

And for SI-3448, the solution lies in automatic usecase generation,
whenever that will be ready.
SI-4360 Adds prefixes to scaladoc

This was a long-standing issue in scaladoc: It was unable to
disambiguate between entries with the same name. One example is:
immutable.Seq:

trait Seq[+A] extends Iterable[A] with Seq[A] ...

What's that? Seq extends Seq? No, immutable.Seq extends collection.Seq,
but scaladoc was unable to show that. Now it does, depending on the
template you're in. Prefixes are relative and can go back:
-scala.collection.Seq has subclasses *immutable.Seq* and *mutable.Seq*
-scala.immutable.Seq extends *collection.Seq*

Unfortunately the price we pay for this is high, a 20% slowdown in
scaladoc. This is why there is a new flag called -no-prefixes that
disables the prefixes in front of types.

Btw, it also fixes the notorious "booleanValue: This member is added by
an implicit conversion from Boolean to Boolean ...". That's now
java.lang.Boolean, so it becomes clear.

Conflicts:

	src/compiler/scala/tools/nsc/doc/model/diagram/DiagramFactory.scala
Scaladoc minor fix: Typos in diagrams

As suggested by Heather in pull request #816.
SI-4887 Link existentials in scaladoc

Based on an inital patch by Nada Amin. Rewrote some of the code to
compress it a bit.

Also fixed a problem that was affecting the prefix printing for
typerefs: type parameter and existentials won't get prefixes. While
I can imagine cases where you'd want to see where they come from,
you can always hover over them and see their origin.

Also added support for pretty-printing ThisTypes, SuperTypes and
SingleTypes (with links)
SI-3695 SI-4224 SI-4497 SI-5079 scaladoc links

Adds the ability to link to members, classes and objects in scaladoc.
The links can now be either qualified names or relative names, they
both work. See the test/scaladoc/resources/links.scala for a usage
example. Also introduced -no-link-warnings scaladoc flag, in case the
build output gets swamped with link warnings.
Scaladoc: Reducing the memory footprint

 - diagrams are not stored because they create many TypeEntities, nodes
and edges -- now they are created on demand, so make sure you don't
demand them twice!
 - eliminated the type entity cache, which was nearly useless (6s gain)
but was preventing the GC from eliminating TypeEntities
 - an unsuccessful attempt at reducing the tons of :: garbage we're
generating - there's 200MB-250MB of ::s during a typical 'ant docs.lib'
Scaladoc: Reducing the memory footprint 2

 - got rid of references to WikiParser when creating EntityLinks
Scaladoc: updated type class descriptions

The known type class descriptions give you a humanly-understandable
explanation for [T: TypeClass] in the implicit conversions. For
example [T: Integral] will tell you that T must be an integral type
such as Integer and co.

Now that the reflection dust settled, I can actually add the test to
make sure the well-known type classes are intercepted and explanations
are given instead of the usual "the type T is context-bounded by
TypeClass"