Add subworkflows and an expansion stack for tracing

[xujustinj]

The latest changes have allowed workflows to be completely interchangeable with nodes. However, when they are expanded, we have no trace of what actually happened. Right now consumers like AceTeam have to hack this into existence by reconstructing a context in their implementations of subworkflows.

Let's make subworkflows one of the core built-in node types. As for tracing, there's a bunch of options. In no particular order:

Option 1

Instead of returning just a Workflow instance, require such nodes to return tuple[Workflow, Context]. That new context object is passed when executing the subworkflow (including on_workflow_start, on_node_start, etc.)

This requires every node that produces a subworkflow to do its own implementation of the subcontext, which I think is a bad idea...

Option 2

Add a on_expand_workflow hook to the Context class. This hook takes the node and the returned workflow, and builds the context to be used when executing that inner workflow's nodes (including on_workflow_start, on_node_start, etc.)

I think this is nicer but one might wonder if this is powerful enough to handle the tracing that users want to do. Specifically, this gives nodes no ability to customize what gets pushed onto the stack.

Option 3

???

[sunapi386]

Option 3 is we properly update and conform all the workflow-engine runs and results to AEP