Resolve UI Location

[Ichthyostega]

Define a Resolver component to serve as anchor for generic UI-Coordinates.

The resolver allows to treat "UI Location" in an uniform way and abstracts away the intricacies of navigating widgets with the help of the concrete UI toolkit. It has in turn to rely on a command-and-query interface, which also needs to be defined to accomplish this task

[Ichthyostega]

obviously, we get a trivial case, when the path is explicit,
and we need a tricky full blown resolution with backtracking
when forced to interpolate wildcards to cover a given UICoord
spec against the actual UI topology.

Do we need it?

• actually not right now
• but already a complete implementation of the ViewSpec concept requires such a resolution

[Ichthyostega]

...so this caused an extended digression, where I've investigated iterative exploring of tree-shaped structures.
As a result of #1117, we're now able to address the generic case in a clean and succinct way. I consider this digression justified, since we've encountered similar challenges several times now, and "ad hoc" solutions tend to be rather messy for that

[Ichthyostega]

Based on this new framework, it was rather straight-forward to implement a full-blown resolver for partially specified UI paths,
including backtracking and best match. Since this whole topic is rather technically involved, I've added extensive unit test coverage;
to allow for such, a dummy implementation of the LocationQuery interface was used, based on a hard wired GenNode tree.
This dummy implementation was also used to verify the design of the tree navigation helper.

The actual implementation of LocationQuery will have to wait for a more complete implementation of our UI, including the
handling of panels, creation and access to view components within these.

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin