prepares our macro defs for refactoring (Step I)

In our codebase we have a bunch of macros, and some of those macros
(namely, tag materialization macros and string context "f" formatter)
are used inside the compiler itself.

The logic of those macros is hardwired into starr's fast track,
so it doesn't rely on any of the subsystems of the macro engine
to be located, bound and executed.

But to trigger this logic we need to color these macros as macros, i.e. as
term symbols having the MACRO flag. Currently this works automatically,
because fast track macros (the same as regular macros) have their rhs
in the "macro ???" form. Having seen the "macro" keyword, the compiler knows
that the corresponding def declares a macro and sets the MACRO flag.

As the latest refactoring attempt has shown, the "macro" in "macro ???"
is unnecessary and might stand in the way of macro refactorings. After all
if some symbol is in the fast track registry, then it's definitely a macro.

Hence I'm changing the compiler to not need the "macro" keyword in declarations
of fast track macros anymore.
prepares our macro defs for refactoring (Step II)

Since the previous commit the compiler doesn't need any help
to find out that fast-tracked macros are macros. Hence I'm
replacing their RHSes with the universal ??? body.

This way macro definitions defined in scala (for example,
tag materialization macros or certain string formatters)
won't stand in the way of the changes to the macro system.
removes -Xmacro-(.*)-classpath compiler options

These options were meant to be used to bootstrap macros defined in our codebase
However we can bootstrap perfectly without any additional effort, because
library classpath classloader can delegate to tool classpath classloader to
load macro implementations from starr.

Since then (for several months) this functionality hasn't proven to be useful,
neither anyone on the mailing list or stackoverflow asked questions about it
(even despite it was explicitly mentioned in the "cannot load macro impl"
error message).

Hence I suggest that it is totally unnecessary and should be removed.
reflect.makro => reflect.macros (Step I)

Builds a starr that uses stuff from scala.reflect.macros for macro activities.
Crucial makro thingies (such as makro.Context or makro.internal.macroImpl)
are temporarily left in place, because they are necessary for previous starr.

Macro tests will be fixed in a dedicated commit, so that they don't pollute
meaningful commits, making the life easy for reviewers and spelunkers.
evicts last traces of makro from our codebase

Removes the stubs left out to appease the old starr, fixes macro tests.
moves Expr from api to base

This is the first step in supporting serialization for exprs and type tags.

Generally speaking universes and mirrors cannot be serialized (even not taking
into account all the amount of scalac-specific transient stuff, java mirrors
use classloaders, which are not serializable).

Hence we can only serialize tree and type creators, and deserialize them into
the mirror we surely know will be there - the scala.reflect.basis.rootMirror.

To do that we need to have exprs in scala.reflect.base. Luckily all the trees
are already in base, we only need to move a single file to scala-library.jar.
Another good news is that reification logic is simplified, because we don't
have to special case exprs as being defined in ApiUniverseClass.
deploys a new starr that knows reify is a macro

reify has just been moved to base.Universe from api.Universe, so the fast track
in the old starr doesn't know about its existence. Therefore locker is built
without reify having the MACRO flag, thus it won't be able to expand reify.

Strictly speaking we don't need a new starr, because reify isn't used in scalac
so, even though locker won't recognize reify, quick will be fine.

However you don't know where a little sloppiness is going to bite you,
so I took time to rebuild and push the new starr.

It was as simple as "ant build starr.done" of the parent commit.
No file mingling was required.
first stab at serialization of exprs and tags

Instead of trying to serialize the entire universe and failing miserably
(which happens now), exprs and type tags will now serialize their creators
and deserialize into scala.reflect.basis.

Since creators produced by reification are not serializable right now,
serialization will crash. That's a small improvement over state of the art
functionality-wise, but it's a step forward robustness-wise.

Next step in this direction is generation of serialization code for creators.
Related issues: SI-5919 and SI-5908. Also see the discussion at scala-internals
http://groups.google.com/group/scala-internals/browse_thread/thread/ef63f8b5bd194c7c