[REG 5.15->6.0] TapHandler.onTapped: device and button are no longer available

The tests/manual/pointer/tapHandler.qml manual test has

             onTapped: { // 'eventPoint' is a signal parameter of type QEventPoint*
                console.log("tapped button " + eventPoint.event.button + " @ " + eventPoint.scenePosition +
                            " on device '" + eventPoint.event.device.name + "' " + (tapCount > 1 ? (tapCount + " times") : "for the first time"))

eventPoint.event does not exist anymore: eventPoint is QEventPoint, and it doesn't have a pointer to the QPointerEvent, because QEventPoint is long-lived while the event is stack-allocated ( https://codereview.qt-project.org/c/qt/qtbase/+/309598 ). Therefore such a pointer would often be dangling unless we are very careful: i.e. an event must never be copied (that's currently mostly illegal), and if an event is moved then those pointers in all its eventpoint instances would need to be updated. In that case, it would be non-null only during event delivery. So we could maybe fix it that way, but it seems like a bad design, as long as events are so much more ephemeral than eventpoints.

On the other hand, it makes sense to store the button state in the event, not in the eventpoint. The QPA API requires passing complete button state from the platform to QGuiApplication along with each mouse event now, so we don't need to store it between events like we used to do in Qt 5.

So maybe we could add the button or the event as a signal argument. The trouble with emitting the event is that we would need to allow copying in this case, because it's a Q_GADGET (aka a value type) not a QObject, so it can't be emitted by pointer. That's possible, but it's against the new Qt 6 policy that we never copy events. Also due to tradition, whenever an event is available, users will think they ought to be able to set accepted to false to continue propagation, but that won't work in such a context where the event is a copy.

At least QEventPoint has a const QPointingDevice * device property. The problem with that has been that the QML engine has always treated const QObject pointers as unique types from non-const ones, so the type registration of const QPointingDevice * is not done at all. QTBUG-82354 is getting fixed, so now we can at least access the device that way in the onTapped signal handler.