rename one of the two confusing MacroExpanders

There were two things named MacroExpander, which was confusing. I renamed
one of them TTMacroExpander.

[breaking change]
use side table to store exported macros

Per discussion with @sfackler, refactored the expander to
change the way that exported macros are collected. Specifically,
a crate now contains a side table of spans that exported macros
go into.

This has two benefits. First, the encoder doesn't need to scan through
the expanded crate in order to discover exported macros. Second, the
expander can drop all expanded macros from the crate, with the pleasant
result that a fully expanded crate contains no macro invocations (which
include macro definitions).
make walk/visit_mac opt-in only

macros can expand into arbitrary items, exprs, etc. This
means that using a default walker or folder on an AST before
macro expansion is complete will miss things (the things that
the macros expand into). As a partial fence against this, this
commit moves the default traversal of macros into a separate
procedure, and makes the default trait implementation signal
an error. This means that Folders and Visitors can traverse
macros if they want to, but they need to explicitly add an
impl that calls the walk_mac or fold_mac procedure

This should prevent problems down the road.
add Macro Exterminator

the Macro Exterminator ensures that there are no macro invocations in
an AST. This should help make later passes confident that there aren't
hidden items, methods, expressions, etc.
auto merge of #15601 : jbclements/rust/disable-default-macro-behavior, r=alexcrichton

Our AST definition can include macro invocations, which can expand into all kinds of things. Macro invocations are expanded away during expansion time, and the rest of the compiler doesn't have to deal with them. However, we have no way of enforcing this.

This patch adds two protective mechanisms.

First, it adds a (quick) explicit check that ensures there are no macro invocations remaining in the AST after expansion. Second, it updates the visit and fold mechanisms so that by default, they will not traverse macro invocations. It's easy enough to add this, if desired (it's documented in the source, and examples appear, e.g. in the IdentFinder.

Along the way, I also consulted with @sfackler to refactor the macro export mechanism so that it stores macro text spans in a side table, rather than leaving them in the AST.