ValOrDefDef.name is now TermName

Back then when we planned to introduce type macros, we relaxed the type
of DefDef.name from TermName to Name in order to potentially be able to
accommodate type names for type macros.

Since then, type macros have been cancelled (and, for the record, my
implementation of type macros in paradise 1.0 didn’t involve DefDefs
with TypeNames), and we’ve rolled back the change to DefDef.name.

What we forgot to do, however, was to change the type of ValOrDefDef.name,
which is taken care of in this commit.
SI-8118 simplifies Annotation down to a plain Tree

As per https://groups.google.com/forum/#!topic/scala-internals/8v2UL-LR9yY,
annotations don’t have to be represented as AnnotationInfos and can be
reduced to plain Trees.

Due to compatibility reasons and because of the limitations of the cake
pattern used in implementing current version of Reflection, we can’t
just say `type Annotation = Tree`, however what we can definitely do is
to deprecate all the methods on Annotation and expose `tree: Tree` instead.
SI-6814 adds typechecker modes to c.typecheck

As per multiple user requests, this commit introduces a shortcut
to typecheck trees under multiple different modes: terms (EXPRmode,
was exposed in Scala 2.10) and types (TYPEmode).

Looking into the rest of a dozen of internal typechecker modes, to the
best of my knowledge, I can’t find other modes that we could expose.
FUNmode is useful, but very situational. PATTERNmode is useful, but
also situational, because we don’t expand macros inside patterns
except for whitebox extractor macros. The rest (e.g. POLYmode or TAPPmode)
are too low-level.
SI-6931 cleans up the position API

I have finally overcome my fear of positions and got to cleaning up its
public interface.

Apparently it isn’t so bad, since there’s a sane core of methods (thanks
to whoever wrote the comments to internal#Position):
  1) Checks to distinguish offsets, opaque ranges and transparent ranges
  2) Essentials that inclide start, point, end and source
  3) Factories that create new positions based on existing ones

It looks like methods from the 3rd group are exactly what we’ve been looking
for in SI-6931, so we have nothing to add in this commit.
SI-8086 addresses problem with calling Symbol.getter

Due to an unintended clash between `def getter: Symbol` (public reflection)
and `def getter(base: Symbol): Symbol` (internal reflection), the former
is uncallable from compiler internals and/or REPL’s power mode.

While both methods are guarded by compatibility constraints, we can’t
solve this problem radically and will have to live with it for some time
Thankfully, a replacement for `sym.getter` is quite approachable, namely:
`sym.getter(sym.owner)`.

In the meanwhile, I’ve deprecated the internal `getter` method by
renaming it to `getterIn`, also touching a nearby `superSymbol`. In the next
release we’ll be able to fix the name clash for good.
SI-6441 removes Symbol.isOverride

`Symbol.isOverride` joins `Symbol.isLocal` in the unfortunate family
of methods for which we had to break source compatibility because of
their utter brokenness.

Apparently, `isOverride` only returns true for those symbols that have
the OVERRIDE flag set (i.e. the ones that are derived from source definitions
that have the `override` modifier specified next to them). Of course,
this is very confusing, and that’s exacerbated by the fact that we can’t
fix this behavior, because there’s `internal#Symbol.isOverride` that someone
might rely on.

Given that there’s perfectly working `Symbol.allOverriddenSymbols`,
this commit removes the `Symbol.isOverride` API altogether.
SI-6732 deprecates internal#Symbol.isPackage

This is the first step in disentangling api#Symbol.isPackage, which is
supposed to return false for package classes, and internal#Symbol.isPackage,
which has traditionally being used as a synonym for hasPackageFlag and
hence returned true for package classes (unlike isModule which is false
for module classes).
deprecates String => Name implicit conversions

Given that in 2.11 we have upgraded our name construction facility
from `newTxxxName` to `TxxxName`, I think it’s time we retire these
implicit conversions, as they no longer save keystrokes, but continue
to present ambient danger associated with implicit conversions.
deprecates api#Name.decoded and api#Name.encoded

Presence of both decoded/encoded and decodedName/encodedName has always
baffled me, as one of those method groups is clearly redundant, and
this pull request presents a great opportunity to address this by
deprecating one of the groups.

After some deliberation, I’ve chosen decoded/encoded as the deprecation
target, because its derivation from decodedName/encodedName is easier
than the other way around.
cleans up Trees a little bit

Adds some clarifications to docs, introduces personally long-awaited
treeCopy.RefTree that lets us deal with RefTrees in a fully uniform fashion.
establishes scala.reflect.api#internal

Reflection API exhibits a tension inherent to experimental things:
on the one hand we want it to grow into a beautiful and robust API,
but on the other hand we have to deal with immaturity of underlying mechanisms
by providing not very pretty solutions to enable important use cases.

In Scala 2.10, which was our first stab at reflection API, we didn't
have a systematic approach to dealing with this tension, sometimes exposing
too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing
too little (e.g. there's still no facility to change owners, to do typing
transformations, etc). This resulted in certain confusion with some internal
APIs living among public ones, scaring the newcomers, and some internal APIs
only available via casting, which requires intimate knowledge of the
compiler and breaks compatibility guarantees.

This led to creation of the `internal` API module for the reflection API,
which provides advanced APIs necessary for macros that push boundaries
of the state of the art, clearly demarcating them from the more or less
straightforward rest and providing compatibility guarantees on par with
the rest of the reflection API.

This commit does break source compatibility with reflection API in 2.10,
but the next commit is going to introduce a strategy of dealing with that.
reflection API compatibility with 2.10.x

This is just one of the possible strategies for compatibility with
reflection API of 2.10.x family. Here’s the discussion:

1) Do nothing.

Document the fact that we’ve organized internal APIs in a separate module
and let people figure out themselves.

Pros: no boilerplate on our side.
Cons: potential for confusion, major upfront migration effort.

2) (This commit). Introduce a compatibility pack with a manual import.
Compatibility pack lives in a separate module that has to be manually imported.
People will get compilation errors when trying to compile macros using
internal APIs against 2.11, but those will be quenched by a single
`import compat._` import. Compatibility stubs would still produce
deprecation warnings, but people can choose to ignore them to alleviate
migration costs.

Pros: brings attention of the users to the fact that they are using
internal APIs by providing a more powerful nudge than just deprecation.
Cons: even though migration effort is trivial, it is still non-zero.

3) Deprecate internal APIs in-place.

Pros: zero migration effort required.
Cons: those who ignore deprecations will be unaware about using internal APIs,
there will be some naming conflicts between Universe.xxxType and internal.xxxType
type factories.
adds Symbol.alternatives

As per Jason’s additional request, this commit exposes alternatives
in the base Symbol type, rather than only in TermSymbol.
adds initialize and fullyInitialize

As per Paul’s request, this commit introduces facilities to force initialization
of reflection artifacts.

Sure, initialize (actually, even fullyInitialize) is silently performed
by Symbol.typeSignature for runtime reflection, but people don’t have to
know about that.
adds Context.enclosingOwner

As per discussion at https://groups.google.com/forum/#!topic/scala-internals/nf_ooEBn6-k,
this commit introduces the new c.enclosingOwner API that is going to serve
two purposes: 1) provide a better controlled alternative to c.enclosingTree,
2) enable low-level tinkering with owner chains without having to cast
to compiler internals.

This solution is not ideal, because: 1) symbols are much more than
I would like to expose about enclosing lexical contexts (after the
aforementioned discussion I’m no longer completely sure whether exposing
nothing is the right thing to do, but exposing symbol completers is definitely
something that should be avoided), 2) we shouldn’t have to do that
low-level stuff in the first place.

However, let’s face the facts. This change represents both an improvement
over the state of the art wrt #1 and a long-awaited capability wrt #2.
I think this pretty much warrants its place in trunk in the spirit of
gradual, evolutionary development of reflection API.