SI-5903 extractor macros do work

Apparently it is already possible to use macros to customize pattern
matching as described in the comments to the aforementioned JIRA issue.

What's even better - with the incoming addition of c.introduceTopLevel
it becomes possible to generate arbitrarily complex unappliers, even
with heterogeneous types of arguments varying from expansion to expansion
refactors handling of macros in repl

Macros now have a dedicated member handler, so that the logic of their
processing doesn't get mixed up with vanilla DefHandler.

I've also factored out an abstract MacroHandler to provides a basis
to build the upcoming type macro handler upon.
makes macro override error more consistent
adds Trees.replace(Tree, Tree)

Currently dead code. Has proven to be useful to implement type macros,
therefore I'm moving it to scala.reflect.internal.Trees.
fixes printing of AppliedTypeTree
changes isTermMacro checks to something more universal

Previously I wanted to be as precise as possible, but as the experience
with type macros shows, a lot of isTermMacro checks should also extend
to include type macros.

Therefore I'm changing the checks to isMacro. This doesn't make any
difference for existing code, but will reduce the amount of changes
in the upcoming type macro pull request.
parentTypes => typedParentTypes

I felt really uncomfortable having to stare at `parentTypes`, when
everyone else in Typers.scala is named typedSomething.
more precise errors for macros
typedPrimaryConstrBody now returns supercall

Previously this method returned the entire block with supercall being
potentially wrapped in early defs.

However when implementing type macros, I found it more convenient to have
typedPrimaryConstrBody to only return the supercall itself. This doesn't
make any difference for our current codebase, since the only time anyone
cares about the return value, it's only to inspect its tpe.

Therefore I'm submitting this patch in a preparatory pull request to
reduce the surface of changes in the upcoming type macros pull request.
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.