Add protocol for pointer (mouse cursor) warping

This is a feature request for a protocol that allows applications to ask the compositor to warp the mouse cursor to a new location.

I understand that the pointer-constraints-v1 protocol provides some facility for warping through the position hint, however this doesn't seem like the right solution for me because the warping is a side-effect of cursor locking (which is not what I'm trying to do) and is optional and so may not even happen.

I understand that there is some sentiment that allowing an application to move the cursor anywhere on the screen may create poor user experience or even security risks, so I want to clarify that I only need cursor warping within a focused application window.

The use cases I have, from KiCad:

1. KiCad implements infinite mouse-drag pan, meaning that when a drag action hits the edge of the rectangular drawing canvas, the cursor is warped to the opposite edge. This allows quick navigation of large drawings, especially with input devices such as trackballs/trackpoint. This particular use case appears to be identical to one brought up in this forum thread by another EDA tool author.
2. KiCad implements an (optional) special zoom behavior that some users find very helpful and productive. When this behavior is enabled, any zoom event (typically from a mouse wheel or keyboard shortcut) will result in the current cursor location being warped to the center of the drawing canvas (as well as repositioning the drawing canvas center). More details can be see in this KiCad issue.
3. KiCad keeps track of a "drawing cursor" separate from the system cursor, that represents the insertion point of new graphic shapes on the editing canvas. This cursor is snapped to a grid but tracks the system cursor when the drawing canvas has focus. When the user performs certain editing operations, a child window (pop-up dialog) may open that the user can interact with. In some cases, KiCad will warp the system cursor back to the last drawing cursor position when such a dialog is closed, so that even if the user interacted with the dialog using the mouse, the editing operation will take place at the last drawing cursor location rather than jumping to a new position (e.g. whatever position is under the dialog's OK button)

KiCad uses wxWidgets as an abstraction layer for cross-platform UI. So, my proposed solution is to have some wayland protocol that can provide similar results to the gdk_device_warp call that wxWidgets uses today on X11/Xwayland, but perhaps with more restrictions (e.g. only allowing warping if the application window has focus, only allowing warping to coordinates that are within the focused window, etc) if desired by the wayland team in order to prevent "bad behavior".