Decompose `Node`

[liamhuber]

The Node class has gotten a bit unwieldy. I feel that the way I added storage, especially on top of two backends that are non-optimal (tinybase being incomplete, and h5io -- most of all -- not accommodating rercursive attributes) has resulted in some technical debt.

This became particularly evident in #240 when I tried to merge storage into Joerg's branch. I knew already that Node.iter didn't play well with the graph paradigm, but with storage present simply creating new copies of the same node with

So what I'd like to do is break apart Node into some different pieces to separate out the concerns and break responsibilities into smaller pieces. I had initially tried a purely component-based composition approach (e.g. Node.semantics.label instead of Node.label), but this proliferated trouble with h5io due to all the recursive relationships. So instead I'm opting for mutliple-inheritance mixin-compositions.

My current attack plan is:

• Semantics to handle labels, uniqueness, child/parent relationships, etc. ([minor] Semantics #244)
• Runnable ([minor] Extract responsibility for run to its own class #246)
  • And later to handle interactions with remote queues
• HasIO to ([patch] HasIO mixin #252)
  • Use case: "single-value-ness" becomes a special case of HasIO where there is only one output data channel, so we can close Add a single_value_macro #155 and reduce the number of user-facing classes (just Function and Macro, no more SingleValue) at the same time. ([patch] Give every node SingleValue power #255, [minor] Purge single value #257)
• Finally, go back and revisit the existing abstraction of storage ([patch] Refactor the storage interface #260)

[liamhuber]

Ok, I'm quite happy with this. I'm quite certain that there is room for improvement, and it's always possible that one goes too far decomposing things into too small of pieces, but overall this feels better. IMO the proof is in the pudding with how easy it was to now give all nodes "single value" power in #255. Critically, pyiron_workflow.node went from an unwieldy 1302 lines down to 729 -- a 46% reduction. There will be more to do in the future, but I feel this is a reasonable stopping point to go harvest some fruit from the improved infrastructure and get feature implementation done.