Rethink structure/function of Location (and Movement) tree

[kvesik]

We're currently dependent on the actual text labels of location & movement tree nodes in order to save/reload/navigate the tree info, which means a whole bunch of annoying little tidbits of "backward compatibility" code whenever we rename/modify something. This needs to be restructured (possibly to use unique node IDs instead?). We need to be able to do things like:

• New: allow users (or us!) to change the text of tree nodes
• New: allow users (or us!) to move tree nodes around, delete them, or add new ones
• New(ish): display appropriate abbreviation tooltips in the visual sign summary window
• Existing: organize in subgroups where necessary
• Existing: store attributes such as whether the node is mutually exclusive with its neighbours, whether or not it's checked, whether it has a user-specifiable value, what its subarea/surface options are (for location only)

This is interdependent with several other existing issues:

• surfaces/subareas lists in location tree: #155
• abbreviations for tooltips in location (and movement) tree: #166
• adding one million new hierarchy restructurings to location tree: #162

[kvesik]

@kchall We are wondering whether the assumption is that users will always start with our default location & movement trees, and then maybe make modifications from those starting points if necessary? Or if there will ever be a scenario where a user will need/want to create their own totally from scratch?

[kchall]

I think it's reasonable to assume they'll start with our defaults, thanks!