Accessing a disabled nested operator throws an error

[bruno-f-cruz]

To reproduce:

1. Add a GroupWorkflow
2. Disable
3. Double click to open

Depending on the complexity of the workflow it sometimes even leads to a deadlock of the editor (cant seem to reproduce this reliably tho)

[glopesdev]

While an immediate fix is easy to apply, working on this has raised a deeper conceptual question about representing disabled nodes, and indeed all nodes, in the tree view.

The issue is whether / how a disabled node should be visually represented in the tree view. Currently it is possible to have a very deep hierarchy disabled at the top-level and there will be no visual indication of this while working on either the workflow node itself, or its children.

We could use an extra tree view icon to represent the disabled state (currently we have editable and read-only). However, because we can still open disabled nodes and edit them, and we can have include workflows inside, we would need 2 extra icons (disabled + editable and disabled + read-only), which might be hard to represent consistently in the UI.

This also raises the more general question about whether tree view "state" is really what we want to use to annotate each level in the tree-view, or whether we should just move to something more general such as the node category and even operator icon. It would be useful to know for each nested level in the tree-view what is the exact operator we are editing at each level, e.g. is it a Defer, Sink, or a SelectMany?

At an implementation level this is not straightforward as it would require custom rendering the tree view to replicate the SVG icon rendering strategy for each tree-view level (or at least rendering all loaded group workflow icons into the image list if we want to use the default renderer), but it might be the most informative long-term.