feat(tree): allow specifying key where tree status is saved

[Killusions]

What kind of change does this PR introduce? (check one with "x")

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior? (You can also link to an open issue here)

Tree status has to be in the row key "treeStatus", this is suboptimal because it does not allow for separation of UI state and data.

What is the new behavior?

A new input allows specifying a (nested) key to be queried (and updated).

Does this PR introduce a breaking change? (check one with "x")

• Yes
• No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...

Other information:

[spike-rabbit]

I don't think we should do this. This adds more complexity internally and I don't see a need for this.

[Killusions]

@spike-rabbit I mean we can argue about allowing recursive keys, but at least specifying the key should be allowed because the datatable should not inform the data structure of the consumer (it also doesn't do this for any of the other functionality).