SI-5856 enables use of $this in string interpolation

This pull request fixes SI-5856. The scanner has been modified
to return the correct token if keywords appear in $-expressions.
The parser has been modified to issue an error and to only accept
$<identifier>, $this and $block.
changes error message generated by compiler
SI-5999 removes Context.reify

Currently there are discrepancies between the behavior of
c.reify and c.universe.reify.

First step in fixing these problems is removing the duplication in the API.
That's why I'm cutting away the Context.reify shortcut.

Context.reify is a magic macro, hardwired in the fast track mechanism, so
removing it requires redeploying the starr (because an old starr will
crash if launched on sources that don't contain Context.reify).

To cleanly redeploy a starr I've left a Context.reify stub in sources,
but hidden it behind a `protected` modifier. When starr is redeployed
(in a subsequent commit) the stub will be removed.

I've also updated the tests to use c.universe.reify instead of c.reify.
This will break some of them, because c.universe.reify uses a standard
compiler mirror, which unlike a macro mirror doesn't like packageless classes.
That's an annoyance, but I think having clean separation of commits
is more important that being 100% consistent.
SI-5999 deploys a new starr

That doesn't require Context.reify anymore.
more meaningful name for a missing hook method
SI-5999 removes the macro context mirror

It is impossible to enforce macro programmers to use this mirror
instead of c.universe.rootMirror, so it has to be let go.

As to packageless symbol loading, which was the sole purpose of
introducing a special mirror for macro contexts, it will be integrated
into the compiler mirror in subsequent commits.
SI-5949 updates documentation of staticClass
SI-5999 staticXXX is now friendly to packageless
an improvement based on Adriaan's comment

"""
why use asTypeConstructor for a prefix?
shouldn't that be BaseUniverseClass.thisType?

also, why does the prefix need to be changed at all?
I'm sure there's a valid reason, but it would be good to document it.
if you don't need to change the prefix,
use appliedType(tagType.typeConstructor, List(tpe))
"""

Because we need to look for an implicit of type base.Universe # TypeTag[$tpe].
I figured out that this is exactly the internal representation of that type.
evicts calls to reify from our codebase

Until reflection design is stabilized (i.e. 2.10.0 final is released),
it's a good idea to refrain from using reify in our codebase
(either directly in quasiquotes, or indirectly via materialized type tags).

This increases the percentage of changes to reflection that don't require
rebuilding the starr.

The change to build.xml will expose reifications going on during our build
(by printing out their results to the console, so that they bug everyone),
making it easier to spot and fix them.
SI-5999 a real fix to the packageless problem

After a discussion on a reflection meeting on Jul 17
we concluded that we should split staticModule into
staticModule and staticPackage to remove the ambiguity
between packageless objects and packageless packages
(more in the comments in the body of the commit).

The motivation is verbosely outlined in the comments,
but the bottom line is that Scala allows packages and
packageless objects to have the same name within the same program.
Therefore at times we need to disambiguate, hence the introduction
of the staticPackage method.

As of such staticModule no longer works for packages.
In the same fashion staticPackage doesn't work for modules.
This is done to ensure robustness of reification.

I would like to do the same for getModule in Definitions,
but we have to maintain backward compatibility. That's why I retained
the old behavior, but replaced getModule invocations with getPackage
where appropriate to be in line with staticModule and staticPackage.

Another important thing that follows from the discussion is that
both staticClass and staticModule prefer parent packages over parent objects
in cases of ambiguity. Say, if we have the following snippet of code:
object B { class C } next to package B { class C }
then staticClass("B.C") will never even consider a C inside the object B.
This is how scalac operates, so we decided to be consistent here.

Finally reification logic got changed to distinguish between
staticModule and staticPackage, and to allow for the fact that
staticClass and staticModule prefer parent packages to parent objects.
Merge pull request #927 from dgruntz/issue/5856

SI-5856 enables use of $this in string interpolation
Merge pull request #936 from scalamacros/ticket/5999

SI-5999 consistent behavior for c.reify and c.universe.reify