Make 'macro statement:foo' and 'is parsed' work

[masak]

This is a work in progress.

Addresses #177.

Still hardcoding various things in here, and definitely not ready to merge this one, but I still wanted to share because I discovered/realized various things.

Do not merge before the following

• For one thing, the refactor Refactor: everything is an object #242. It's much easier for that one to land and then we rebase this one, than the other way around. But Refactor: everything is an object #242 will not merge, so that's... fine.
• Also, @vendethiel's work in More advanced regex features. #239. This solution is going to need to change based on the ways regexes expand and become more powerful. Specifically, see More advanced regex features. #239 (comment). More advanced regex features. #239 has merged now.

What I realized

• We're going to have to register/store custom statements just the same as we do operators. The logical place to do this is OpScope. (Which indicates "opscope" is perhaps not the best name for it!) Not a big problem in itself, but I hadn't thought about this before. All the categories that can be declared/extended in 007 will need to end up in an opscope-like thing.

• (The big one:) The statement:whoa thing is not a macro expansion as such. An expansion is an AST → AST transformation. But statement:whoa transforms from textual source directly to AST. Proximally, this means that there's no "unexpanded AST" that the parser can produce for this statement. What could we reasonably put there? A blank Q::Statement? (Then we cannot make Q::Statement an abstract type.)

• Also, excitingly, I had to split the utility method expand in Actions.pm into expand (for this use case) and expand-expr (for all the previous ones). It turns out we've only ever expanded macros into an expression, but in this case we're expanding it into a statementlist. In that case, we are not supposed to do the dance of wrapping things into a Q::Expr::StatementListAdapter.

[masak]

A couple more comments.

• "Lisp reader macros" (there is such a thing, right?) come to mind. I think is parsed macros are simply our analogue.
• What we should un-expand is an object saying "and here, we parsed this bit of source code". The unexpanded version of an is parsed macro is a bit of source code, gussied up as a Qnode.
• Clearly, this whole thing (is parsed macros) is a deliberate cheat/conflation that's meant to benefit the macro author. We provide both AST → AST transforms and source → AST transform using roughly the same mechanism. The fact that I didn't spot the difference before starting to implement this is testament that the conflation works. Oh, and if lying in this way works out all the way, then I'm completely fine with it.
• Look at me explaining this once here and getting it wrong myself: there aren't two steps is parsed + macro-expand; sure, parsing happens first, and a Qtree is generated second, but there's no intermediate Qtree that the final Qtree is being generated from; the transform happens directly from source to Qtree.