Add signal grouping

This draft retires !391 (closed) - after the feedback in a call to make the grouping more generic and not only for the "Group" items this is the new idea.

Currently still WIP (it's actually crashing when dragging an element sometimes...) but it should give an idea where this would go - and it at least renders...

I decided to make the tree "fully" decoupled from the remainig logic and also move most of the functionality there. The tree itself is implemented in a list vs. a tree since it's much saner to provide (somewhat) stable indices, iteration and movement up the tree, compared to trying to build it as a "real" tree in memory. There is only the depth stored together with a node so that there is no redundant information to update. I did some test with ~1000 signals (similar to an SoC debugging session I'd do at work) and it seems to perform like the non-hierarchical version. Should we need to change this then it shouldn't be too hard in the future to do so.

It's decoupled in the sense that the remaining application has to decide whether it's fine to move a signal below another, etc. so we can decide on limitiations, etc. separately. What this allows us to do in the future would e.g. be:

• Instead of having spade-decoded signals tied to the signal they are decoded from, we could auto-insert separate signals for the decoded variables. Allow them to be moved out/back in, but nothing else to move in
• ...

I moved the attribute whether an item is selected into the tree as this makes it a bit simpler when moving them around, etc. For a stable focus I'm thinking of storing the ItemRef to the focused element, as that would also be stable when moving etc. and the cost of finding the indices are not that high (iteration over array is cheap, and could be cached though I'd like to avoid that).

What this does add is another layer of indexing:

• VisibleItemIndex: the n-th signal we see on screen (invalidates with every fold/unfold/change)
• ItemIndex: the n-th item in the in-order tree (invalidates with tree modifications)
• ItemRef: the loaded signal ref but this does seem fine in general. I did not try to use rust features to limit the lifetime of the shorter-lived indices. They are as volatile to use as the current system and this seemed to limiting. If we are afraid about stale indices then I'd add some generation counter to detect stale ones (at least in debug...)

W.r.t. what the UI should look like w.r.t. moving into/out of a group:

• The insert marker will be indented to the level we are inserting into
• At the end of a group it should be possible to "choose" the indentation level by going left/right with the cursor, but I'd keep that for a later commit, this one is going to be huge enough.

Generally open points:

• simplify tree code, just discussed with a colleague and maybe I shouldn't have written it in my breaks between sauna sessions ;-)
• fix crash...
• fully migrate selection
• implement grouing APIs
• remove redundant API functions from tree, name cleanup
• remove selection API? (use iter_mut etc. from the app)
• split the tree itself from the visibility handling, but not so sure about that
• consistently replace old index types
• make tree generic?
• general integration cleanup, consistent variable names, etc.
• visual changes: indentation, fold marker, etc.
• make struct for extra iterator and add last to save on some scans

One general point: once the crashes are solved and render works as expected w/o the groups - should we think about merging this so that it doesn't rot too much?