Saving state, stage 2

Follow-up from #352

The goal is to save/restore any extra state that allows to render audio, not necessarily global UI settings (somehow best handled with a VFS abstraction and config files I think).

- [ ] Find a binary-serializable, nestable, thread-safe, with key-values, suitable for large blocks of data.
- [ ] Probably take an existing data format like CBOR, BJSON, etc. Something with 1:1 human readable version would help. Not Turtle lol. A DOM but for data.
- [ ] A big point is to handle the bidirectional communcation for UI and DSP. Same problems as Parameter, who lacked two interfaces for each view. Probably we need an algorithm of tree merging?
- [ ] Typical Java UI library have listener that listens to generic `Event`. This is useful when we don't know yet that there will be a button widget with an `onButtonClick` event. See also Javascript solutions. If we do State V2, ideally it should be able to replace _any_ such listener. Mouse, keyboard, and params would be branches of the tree.
- [ ] Make such variant values have Listener of their own, callback on add/remove, things like that

- [ ] **Would be very useful for feedback.** See `feedbacllogic.d` in Auburn codebase. State v2, if it's to be used as the juce ValueTree, needs string interning like LV2 or compilers. Similar to namespaces/environments,, need fast identifier access.
- [ ] Now very important: should this DOM also be the UI tree?

Start by reading the linked follow-up issue #352 and the referenced feedbacllogic.d in the Auburn codebase. Compare the proposed serialization, listener, UI/DSP communication, and UI-tree requirements before choosing an approach. Done would require a settled design and implementation plan for the state model, rather than resolving one isolated checklist item.

Written by the indexing model from the issue text.