PointerHandlers are visited in forward order, but the last-declared should be visited first

A possible (oversimplified) Button implementation:

import QtQuick 2.10
import Qt.labs.handlers 1.0

Rectangle {
    id: root
    property alias label: buttonLabel.text
    signal tapped

    implicitHeight: buttonLabel.implicitHeight * 1.2
    implicitWidth: buttonLabel.implicitWidth * 1.3
    width: implicitWidth; height: implicitHeight
    color: th.pressed ? "tomato" : "wheat"
    border.color: "beige"
    Text {
        id: buttonLabel
        anchors.centerIn: parent
    }
    TapHandler {
        id: th
        objectName: "button"
        onTapped: root.tapped()
    }
}

The use case:

import QtQuick 2.10
import Qt.labs.handlers 1.0

Rectangle {
    id: scene
    color: "#221"
    width: 320; height: 240
    TapHandlerButton {
        label: "tap me"
        onTapped: console.log("TADA")
        TapHandler {
            objectName: "override"
            gesturePolicy: TapHandler.WithinBounds
            onTapped: console.log("tada?")
            grabPermissions: TapHandler.CanTakeOverFromHandlersOfSameType
        }
    }
}

The "override" handler is the second handler to get the event, even though the user's intention was to be first, to override behavior, by being "on top of" the internal handler. That is because it is appended to the Rectangle->private->extra->pointerHandlers vector, in QQuickItemPrivate::data_append(), after the Button component is completed. If this were using MouseAreas instead, it would be the other way around. Even if a declaration of an Item with multiple MouseAreas inside occurs in a single QML file, the one which is declared on the bottom would get the press event first, because of having a higher Z order. So it seems we should make the ordering of Pointer Handlers consistent with that.

QQuickSinglePointHandler::wantsPointerEvent() currently returns false for any point which is already grabbed by another handler, so even though the "override" handler does see the event, it does not try to steal the grab.

Now that we have grabPermissions it should be easier for the control author and the user to negotiate grab stealing. But of course if the "override" handler is actually visited first, there may not be a need for it.

The next problem in this kind of scenario is how can the user's handler delegate some functionality to the internal handler...