Fixes#2513
If a node inside a subflow accessed its context object in its
constructor, the subflow-instance flow context would not yet
have been created. This would cause a place holder context
to get created on its behalf, but that place holder doesn't
have its parent set properly. This then breaks the usage
of $parent inside such a subflow.
This fix has changed it so flows (and subflows) create their
flow context as part of their initial creation. That ensures
it exists when individual nodes from the subflow are created,
allowing them to safely access their context.
This has also fixed a related issue where any attempt to use
$parent to access beyond the root parent would seemingly hang
as the callback was never being called. This would cause
messages to get stuck in flows. The fix ensures the callback
is used in the root context objects and undefined is returned.
Fixes#2358
This property can be used to identify the full path to the node that
logged a given message. If the node is inside a subflow (and maybe
nested many levels deep), this path can be used to help find the
node, rather than just the top-level subflow instance node.
A side-effect of this change is the Debug sidebar is now able to
show the message tools for a message coming from a deeply nested
subflow
Closes#1747
This was inspired by a PR from @mauriciom75 but implemented in a different way
due to some of the internal reworking done to Flow and Subflow in the dev branch
