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.
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
SI-6362 & SI-5924 removes caches in the macro API

As recent experience shows, it's hardly possible to provide a global cache
that persists between compilation runs: http://groups.google.com/group/scala-ide-user/browse_thread/thread/b1cab5588ff21f7f.
Therefore I think we need to remove Context.globalCache.

Speaking of a per-run cache, it looks like Context.cache can be
to a certain extent emulated with attachments. Otherwise, one could write
a JVM-wide static cache weakly indexed by compilation run instances
(that are available via c.currentRun).

For now I think we need to remove both caches. If macro writers really need
that functionality, we could come up with a well-thought API later.
Merge pull request #1302 from scalamacros/topic/reflection

cleaning up reflection