Ability for extensions to define an AST processor

[colinodell]

The process of converting Markdown to HTML is basically two steps:

1. Parse the Markdown into an AST
2. Render the AST as HTML

Users can manually add a third step in the middle to modify the AST before it is rendered. However, it's currently impossible to insert an AST processor via the extension functionality.

I'd therefore like to add support for this within the extensions.

Now, we do have something called inline processors which are executed at the very end of that first step. It's geared towards processing inline AST elements, but perhaps we can make this more generalized?

[hason]

I proposed a similar functionality in #106.

[colinodell]

Yeah I'd like to do something similar to #106, where multiple "visitors" can be defined, and they modify the AST in between the parsing and rendering steps. The main difference is that each "visitor" will be passed the document root Node - they can work directly off that, or use the NodeWalker to iterate through the different nodes. (This wouldn't use the "visitor" pattern, so we'd need to call them something else.)

[colinodell]

For clarification, I'd like the implementation to look something like this:

foreach ($this->environment->getASTProcessors() as $processor) {
    $processor->process($documentRoot);
}

Very similar to how inline processors work, except each "AST processor" (or "AST filter", if you prefer that name) operates on the root-level Document node. Each processor/filter can decide how it wants to manipulate the AST - maybe it'll use a NodeWalker, but it doesn't necessarily need to.

[colinodell]

And to further clarify: I'd like to see if we can remove inline processors and have them use this new approach instead.

[colinodell]

(Removed up-for-grabs tag since @marijnvdwerf is almost done implementing this via #210)