Scope macro interactions by module

[jakobjpeters]

Implements the API described here. Hopefully you'll hear back about how DynamicQuantities.jl does it soon :)

Turing.@model and MacroTools.@capture are still getting special treatment and I don't think they should be built-in to the macro table, but there's not currently a way to make the default behavior extensible. This PR improves the situation overall though!

Closes #43

[github-actions]

Benchmark Results

	main	c6b787d...	main/c6b787dc5d25e4...
_stable/mode=disable	0.731 ± 0.019 μs	0.721 ± 0.019 μs	1.01
_stable/mode=error	0.526 ± 0.017 ms	0.682 ± 0.017 ms	0.772
_stable/mode=warn	0.519 ± 0.036 ms	0.676 ± 0.03 ms	0.769
time_to_load	0.0681 ± 0.00067 s	0.0694 ± 0.0018 s	0.981

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

[MilesCranmer]

Can we leave register_macro! for backwards compatibility for 0.4 and have it declare the macro for Main (which was the previous default)?

[MilesCranmer]

Does this check for hierarchies? Like if I define one behavior for Main, one behavior for Main.A, and one behavior for Main.A.B, will it select the most specific option?

(Maybe we should be relying on multiple dispatch to do this automatically for us...)

[MilesCranmer]

Just out of curiosity why have (::Module => ::Symbol) => ::MacroBehavior as the table? Does it hash faster or something compared to a tuple? Also why not have ::Symbol => [(::Module => ::MacroBehavior), (::Module => ::MacroBehavior)]?

[jakobjpeters]

Also why not have ::Symbol => [(::Module => ::MacroBehavior), (::Module => ::MacroBehavior)]?

Purely because I didn't want to search the array and the module-macro pairs are unique anyways. I'm not otherwise attached to that implementation.

[jakobjpeters]

Does it hash faster or something compared to a tuple

Oh, it's probably the same, I just like pair syntax and again am not attached to it.

[jakobjpeters]

Can we leave register_macro! for backwards compatibility for 0.4 and have it declare the macro for Main (which was the previous default)?

Done!

Does this check for hierarchies? Like if I define one behavior for Main, one behavior for Main.A, and one behavior for Main.A.B, will it select the most specific option?

It didn't, but does now!

(Maybe we should be relying on multiple dispatch to do this automatically for us...)

How so?

[jakobjpeters]

I speculated that mutating the table in the new test had a run-time order dependent effect, that seems to not be the case. I'm not sure what's causing the error.