Compat behaviours: typeof quoted expressions, macro def signatures

[mlechu]

The last two major pieces needed for compatibility with existing code (that I
know of 🙂):

1. The type of quoted code (and return type of many macros) should be Expr.
   This is done by adding a return type parameter to interpolate_ast, which is
   supplied at macro-expansion time (and in the case of @SyntaxTree,
   hard-coded to SyntaxTree).
2. Macro definitions should have the old

   __source__::LineNumberNode, __module__::Module, stuff...
   

   signature instead of the new

   __context__::MacroContext, stuff...
   

Unlike with calling old-style macros (#33), we do need a short-term way to turn
compat behaviour off. I've tied it to a a parameter to lowering that lives in
context until the end of desugaring; other suggestions are welcome.

TODO: Run most tests in both modes

[c42f]

Nice, we definitely need this!

I think a few things here should be implemented a bit differently in the longer term (AST interpolation, eval parameters (eventually hooks for eval (??))) though we could go with this more or less as-is and circle back.

There's obviously the longer term question of how expr_compat_mode should be set. My feeling is that it should eventually be a per-module configuration option that eval() reads. And that's set by some system for syntax evolution which probably relates to a package's Project.toml.

[c42f]

Oh, this is a rather interesting approach. Preserving SyntaxTree in the IR as the definitive as-parsed representation is cute.

With this approach I'm concerned the logic in _interpolated_value doesn't make sense.

• When interpolating values into SyntaxTree, we currently assume SyntaxTree is AST, and everything else is K"Value" (ie, a leaf)
• When interpolating values into Expr, the existing system assumes Expr and LineNumberNode are pieces of AST, and everything else is a leaf (QuoteNode is a bit of an oddity ... is it both?)

There seems to be two ways out:

1. We could take a union of all these rules and support bidirectional interpolation of Expr-into-SyntaxTree and vice versa.
2. We can convert ex to an Expr at lowering time then implement interpolate_ast for Expr separately.

I feel like (2) would be a good conservative option for now. But at least we should make a note about these issues.

Suggested change

	Expr(interpolate_ast(SyntaxTree, ex, values...))
	# TODO: Adjust `_interpolated_value` to ensure that incoming `Expr` data structures are treated
	# as AST in Expr compat mode, rather than `K"Value"`?
	# Or convert `ex` to `Expr` early during lowering and implement `interpolate_ast` for `Expr`?
	Expr(interpolate_ast(SyntaxTree, ex, values...))