generalizes macroExpand

Changes macroExpand to accommodate expansion schemes different from the
currently supported one.

As a bonus, which follows clarification of the macro expansion logic,
this refactoring fixes suppression of macro expansions, which
previously didn't work with delayed expansion.
SI-5923 adapt macros when they are deferred

Amazingly enough, the fix for the "macro not expanded" problem was super
easy. (And I remember spending a day or two trying to find a quick fix
somewhen around Scala Days 2012!)

The problem was in the implementation of the macro expansion trigger,
which was buried in a chain of if-elif-elif. This meant that macro
expansion was mutually exclusive with a lot of important adaptations, e.g.
with `instantiate`.

More precisely, if an expandee contains an undetparam, its expansion
should be delayed until all its undetparams are inferred and then retried
later. Sometimes such inference can only happen upon a call to instantiate
in one of the elif's coming after the macro expansion elif. However this
elif would never be called for expandees, because control flow would always
enter the macro expansion branch preceding the inference branch.

Consequences of this fix are vast. First of all, we can get rid of the
"type parameter must be specified" hack. Secondly and most importantly,
we can now remove the `materializeImplicit` method from Implicits and
rely on implicit macros to materialize tags for us. (This is a tricky
change, and I'll do it later after we merge as much of my pending work
as possible). Finally, we learn that the current scheme of interaction
between macros, type inference and implicits is, in principle, sound!
macroExpandAll is now triggered by typed

Previously delayed macro expansions (the sole purpose of macroExpandAll)
were triggered by `typedArgs`. Probably I wanted to save CPU cycles on
not checking whether we have pending macro expansions on every iteration
of typecheck.

However this optimization is uncalled for, because the check just entails
reading a var, therefore benefits of the current approach are negliible,
whereas the robustness hit is tangible.

After delayed macro expansion mechanism became more robust, it exposed
a bug, well-hidden before. If one first delays a macro and then finds out
that the expandee is erroneous, subsequent `macroExpandAll` will crash,
because it expects a macro runtime attachment to be present. Previously
the erroneous code path never got triggered, because the macro expansion
never commenced. Luckily the fix was easy.
org.scala-lang.macro-paradise
type macros beta v2

No spec yet, just docs at http://docs.scala-lang.org/overviews/macros/typemacros.html.
List of known issues: https://issues.scala-lang.org/secure/IssueNavigator.jspa?mode=hide&requestId=11912.
SI-6859 type macros no longer crash sbt

By mimicking alias types, macro types no longer trip a sanity check
in sbt 0.12 and 0.13: https://github.com/harrah/xsbt/blob/ef39aeb9c1ea443c17356695758a31152910c4a7/compile/interface/src/main/scala/xsbt/API.scala#L221.

This workaround makes me sad but it's the only option to make type macros
immediately useful. Principled fix pending.
quasiquotes milestone 2

No spec yet, just docs at http://docs.scala-lang.org/overviews/macros/quasiquotes.html.
List of known issues: https://issues.scala-lang.org/secure/IssueNavigator.jspa?mode=hide&requestId=11912.