new starr that supports macro ???
less magic in fast track macros

Now that we have a mechanism to declare not implemented macros, let's put
it to good use by reducing the amount of magic applied to fast track.
SI-7461 c.typeCheck(silent = true) now suppresses ambiguous errors

Otherwise use cases like the one shown in the attached test (trying to
typecheck something, which leads to an ambiguous overload error) will
mysteriously fail compilation.
macro engine refactoring

Macro impl bindings now store more information in signatures.
Previously it was a flattened List[Int] corresponding to flattened paramss,
now it's List[List[Int]] to preserve the lengths of parameter lists.
Also now we distinguish between c.Expr parameters and others.

Previously actual and reference macro signatures were represented as
tuples of vparamss, rets, and sometimes tparams. Now they are all
abstracted behind MacroImplSig.

Finally this patch provides better error messages in cases of
argsc <-> paramsc and argc <-> paramc mismatches.
refactors macro tests

putting in a nutshell, this patch:
  * condenses some macro-XXX-a/b/c/... bundles
  * renames some tests to prepare for other macro flavors
  * introduces some additional tests
refactors importers

Introduces better names, factors out recreation of symbols, trees, types
and completes into separate methods, so that they can be overridden in
specialized importers.

The original motivation for this refactoring was to support JIT
compilation of macros, but I think that most of the introduced
improvements to code quality will be useful in trunk.
refactors macro compilation

Upgrades the way that macro defs are compiled by factoring out most of
the logic in typedMacroBody and related errors in ContextErrors into an
standalone cake. This leads to tighter cohesion and better code reuse
as the cake is isolated from the rest of the compiler and is much easier
to evolve than just a method body.

Increased convenience of coding macro compilation allowed me to further
clarify the implementation of the macro engine (e.g. take a look at
Validators.scala) and to easily implement additional features, namely:

1) Parameters and return type of macro implementations can now be plain
c.Tree's instead of previously mandatory c.Expr's. This makes macros more
lightweight as there are a lot of situations when one doesn't need to
splice macro params (the only motivation to use exprs over trees). Also
as we're on the verge of having quasiquotes in trunk, there soon will be
no reason to use exprs at all, since quasiquotes can splice everything.

2) Macro implementations can now be defined in bundles, standalone cakes
built around a macro context: http://docs.scala-lang.org/overviews/macros/bundles.html.
This further reduces boilerplate by simplifying implementations complex
macros due to the fact that macro programmers no longer need to play
path-dependent games to use helpers.
refactors macro runtimes

Following typedMacroBody, macroRuntime along with its friends has also
been moved out into a separate component.
changes some definitions to use Symbol.map
applying Jason's aesthetics suggestion
more refactoring and explanations in importers
refactors IMPLPARAM_xxx constants into value classes
Merge pull request #2577 from scalamacros/pullrequest/paradise

Backport from paradise/macros