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
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
Remove extraneous null check in RedBlackTree

This changes the RedBlackTree foreach method to be be a simple wrapper around
a slightly shorter function, without an unnecessary nullity check.
test suite for SI-6329
A little cleanup along the Any to AnyRef trail.

Followup to 35316be and d3f879a.

 - Remove obsolete comments and replace them with a test.
 - Don't emit error addendum unless we know we're dealing
   with a value class.
magic classes are no longer entered twice

Previously magic classes such as NothingClass were entered twice
into root mirrors of java universes. No idea how this managed not to blow up.
Now this problem is fixed.

Also, as usual when I gain understanding of something, this allows to come up
with better names. `magicSymbols` are now split into three collections:
`magicallyEnteredClasses`, `magicallyEnteredMethods` and `magicallyHijackedSymbols`.
Fix for SI-6245 with workaround for SI-2296.

protected/super accessor issue: Don't subvert the creation of the
standard protected accessor with the java interop accessor. For
SI-2296, the compiler emits an error instead of causing an illegal
access error at runtime.
Added constant empty array to the companion objects.

Because there are lots of times when you just need an
array and shouldn't have to allocate one every time or
pick a random spot to cache yet another empty array.
Optimization in ZipArchive.

There's that empty array.  When compiling "trait Foo", this
took me from allocating 44,410 empty arrays to allocating
383 of them.
SI-6373 removes Trees#ApplyDynamic from the API

Introduced by erasure - therefore it can be seen
neither by macros, nor by runtime reflection.

Despite never being pickled, ApplyDynamic is supported by unpickler
so I couldn't move it exclusively to scala-compiler.jar.

Figuring out the mysterious reason for pickling ApplyDynamic is left
to future work.
SI-6365 removes Symbol.hasAnnotation from the API

It's clearly redundant and also is susceptible to initialize-based bugs.
SI-6369 removes Type.narrow from the API

Looks like narrow doesn't help us solve the problem it was intended for:
http://groups.google.com/group/scala-user/browse_thread/thread/9f5d55ebfcc8e60a

I believe we'll be on a safer side if we remove it until it's really needed.
Merge pull request #1304 from paulp/topic/empty-array-optimization

Topic/empty array optimization
Merge pull request #1299 from namin/si-6245

Fix for SI-6245 with workaround for SI-2296.
Merge pull request #1290 from retronym/ticket/no-implicit-to-anyref

A little cleanup along the Any to AnyRef trail.
SI-6371 adds comments for Trees#UnApply

Unfortunately we cannot remove this node, because it's emitted by typer
and, therefore, can be seen by macros and pickled as a part of annotations.
Therefore we have to expose UnApply in the API.

Experimental status of scala-reflect.jar will give us some leeway to evict it
from the compiler (and consequently from the API) by 2.10.1.
SI-6372 cleans up the API of Attachments

Previously Attachments allowed multiple attachments that
correspond to the same attachment type.

This created a potential for confusion, given that Attachments.get
only searched for the first attachment of a given type.

Hence I made Attachments.add overwrite previously existing attachments
of a given type and renamed it to Attachments.update, so that the name
suits the intention better.
SI-6360 revises naming of AnnotationInfo and its members

Internal face of AnnotationInfos is bound by backward compatibility
with compiler plugins and possibly SBT, but the public face can
be shaped in whatever fashion we like.

Hence I cleaned up the names: AnnotationInfo itself got renamed to
just Annotation, AnnotArgs got renamed to just Arguments and so on.
SI-6342 cleans up toolbox API

1) parseExpr => parse
2) runExpr => eval
3) Introduces compile(Tree): () => Any, since it has frequent uses