SI-6258 Reject partial funs with undefined param types

This regressed with virtpatmat.

With -Xoldpatmat, pattern matching anonymous functions with
an expected type of PartialFunction[A, B] are translated to
a Function tree, and typed by typedFunction, which issues an
error of the parameter types are not fully defined.

This commit adds the same check to MatchFunTyper.

It doesn't plug the hole in RefChecks#validateVariance (which is
reminiscent of SI-3577.) Seems to me that in general one should handle:
  a) both BoundedWildcardType and WildcardType
     when in a place that can be called during inference, or
  b) neither otherwise
SI-3577 Make varianceInType aware of BoundedWildcardType.
Make RefChecks#validateVariance aware of BoundedWildcardType.

The only test case that I know for this will be neutered
by the imminent fix for SI-6258; so I haven't been able to
test this.

But trying this manually, you can see that this patch defers the
the SI-6258 to the erasure phase.

Original:

scala.MatchError: ? (of class scala.reflect.internal.Types$BoundedWildcardType)
	at scala.tools.nsc.typechecker.RefChecks$RefCheckTransformer$$anon$3.scala$tools$nsc$typechecker$RefChecks$RefCheckTransformer$$anon$$validateVariance$1(RefChecks.scala:894)
	at scala.tools.nsc.typechecker.RefChecks$RefCheckTransformer$$anon$3.validateVariance(RefChecks.scala:965)

Modified:

java.lang.ClassCastException: scala.reflect.internal.Types$TypeRef$$anon$6 cannot be cast to scala.reflect.internal.Types$TypeBounds
	at scala.reflect.internal.Types$TypeMap.mapOver(Types.scala:4160)
	at scala.reflect.internal.transform.Erasure$ErasureMap.apply(Erasure.scala:156)
Mention BoundedWildcardType in "a standard type pattern match".
Deprecate unmaintained/old classes for removal in 2.11
SI-5767 fix + small HashSet/HashMap fixes

- `LinkedHashSet` implementation moved from `FlatHashTable` to `HashTable`
   - `remove` time reduced from O(n) to O(1)
   - `diff` time reduced from O(n^2) to O(n)
- A bit of refactoring in `HashTable` serialization code
- Putting an element into hash map now avoids double hash code/hash index
  calculation (see `HashTable#findOrAddEntry`)
- bugfix: compiler/LambdaLift occasionally breaks LinkedHashSet integrity
exposes Symbol.children

As requested in http://stackoverflow.com/questions/12078366/
adds ClassSymbol.baseClasses

Sure this stuff is also declared in Type.baseClasses, but this is
one of the hot paths in reflection (e.g. like ClassSymbol.typeParams),
so I think it's justified to have it as a dedicated method.

Unfortunately we cannot remove Type.baseClasses, because it includes
ridiculously involved calculation of base classes for compound types.
adds Symbol.isJava

Doesn't seem to be inferrable from the API we expose right now
Exposes Symbol.deSkolemize to macros
exposes MethodSymbol.isPrimaryConstructor

Doesn't seem to be inferrable from the API we expose right now
Exposes ToolBox.classLoader

By giving ToolBox.mirror the correct type and constructing the underlying
mirror from a proper classloader, we improve user experience w.r.t
runtime code generation.

Direct motivator: http://stackoverflow.com/questions/12122939, in which
instances of a toolbox-generated class are accessed with Scala reflection.
Fix SI-4581.

Specifically, the final flag on the generated static field
is no longer ommitted.

Fix 2 failing test-cases.
removes AbstractFileApi

no longer necessary, since scala.tools.nsc.io.AbstractFile
has been long moved to scala-reflect.jar
rehash of source file information for Symbol

Symbol.pos is moved to macros.Universe, because it's empty at runtime.

Also added Symbol.associatedFile, because it has valid usages during runtime.
When reflecting one might want to get to a classfile of the symbol and then
analyze it to e.g. decompile the bytecode or find out the associated src file.
Exposes Symbol.sourceModule

As discussed, this is not the best API to expose, because this is an
implementation detail that might change.

However the ship has sailed. We're already imposing
the moduleClass <-> sourceModule quirk to the users of our API:
Evidence: http://stackoverflow.com/questions/12128783.

There are reflection tasks that cannot be pulled without the knowledge
of this implementation detail, so we shouldn't pretend that we can
change it on a whim and not break anything.

Hence I propose to add sourceModule to the public contract
and bear the potential consequences.
definitive way to learn if a symbol is a val/var

I think `isVal` and `isVar` are the right names, because they
exactly map on Scala syntax.
Rank based take/drop/slice.

Tree navigation based on node rank is faster than using compare
method. rank is simply count(tree.left) + 1.
Making public methods of FlatHashTable protected

As discussed in https://groups.google.com/forum/?pli=1#!topic/scala-internals/1yABM30POS0
Fix SI-6294.