Core: support named "transient" nodes in the eval function

[adelhult]

Is your feature request related to a problem? Please describe.

Note: This is mostly a reminder to deal with this issue later once the rest of the system starts to take shape. We have talked about supporting what we call named transient nodes; nodes that just exists in the document tree and get directly translated by another transform (like Row and Column produced by a table module).

When working on the first pass of the Context::transform function we realised that this can get rather complicated, at least when compared to the relatively simple approach of only allowing a single package to be responsible for a module invocations from A->B.

Imagine an example like this, what transform should we chose and from what package?

We have specifed "--target html" to the cli
and have the following transforms loaded:

        Foo -> Tex (provided by package foopack)  
        Foo -> Bar (provided by package foopluspack)
        Foo -> Html (provided by package foopluspack) <-- Easy, we choose this one. 

Imagine instead:

        Foo -> TeX  (provided by package foopack
        Foo -> Bar  (provided by package foopack)
        Foo -> Baz  (provided by package foopack)
        Bar -> Html (provided by package foopluspack)

This scenario is not as easy to solve, since we can't transform directly into the output format, should we use the Bar or Baz transform? To solve this, we would likely need to use an algorithm like Dijkstras. This is not too terrible but a lot of the code gets much simpler by just opting for the more limited approach.

We decided to use the simpler approach for now, and once we get a grip on the scheduling and have a running example go back and take a look and evaluate if the benefits of named transient nodes outweigh the cost of implementation.

Describe the solution you'd like
Support for transient nodes like Row that allow other packages to "hook" into other modules and extend them with extra output formats. Adding this later should not be a problem for the user-facing API since we likely want to support both named nodes and anonymous "compounded nodes" too.

Describe alternatives you've considered
If it ends up being to complicated or provides less value then other features, we might end up skipping this.

Additional context