Rewrite Alt+Right next-element functions as a tree-traversal

The EngravingItem::nextElement() and EngravingItem::previousElement() virtual functions define the order in which elements are visited by the Alt+Right and Alt+Left navigation shortcuts.

The way these functions are currently written, they must be overridden by every EngravingItem subclass to determine what comes next in the sequence. However, there is no guarantee that the sequence is consistent, correct, or complete. Ideally, all interactive elements should be included, while all non-interactive elements (e.g. Page, System, etc.) should be excluded.

These functions could be greatly simplified by rewriting them as a tree-traversal, which could look something like this:

EngravingItem* EngravingItem::nextElement()
{
    // Return first child if there is one.
    for (EngravingItem* child : children()) {
        if (child) {
            return child;
        }
    }
    // Otherwise return next sibling in ancestor element.
    EngravingItem* current = this;
    while (EngravingItem* parent = current->parent()) {
        EngravingItemList siblings = parent->children();
        auto it = siblings.cbegin();
        for (;; ++it) {
            IF_ASSERT_FAILED(it != siblings.cend()) {
                break;
            }
            if (*it == current) {
                ++it;
                break;
            }
        }
        for (; it != siblings.cend(); ++it) {
            if (EngravingItem* sibling = *it) {
                return sibling;
            }
        }
        current = parent;
    }
    return nullptr;
}

EngravingItem* EngravingItem::nextNavigableElement()
{
    for (EngravingItem* next = nextElement(); next; next = next->nextElement()) {
        if (!next->flag(ElementFlag::NOT_SELECTABLE)) {
            return next;
        }
    }
    return nullptr;
}

But which tree should we traverse? There are several possible candidates for the parent() and children() functions.

We'll need to use the one that gives the closest match to the current next-element sequence.

We may still need to override nextElement in a few subclasses, for example, to ensure that navigation stays in the current staff rather than going up and down the segments.