Synchronized Wayland popup moving

Quoting the protocol commit message:

Moving can be done in two ways: implicit and explicit.

Implicit popup moving is done by setting a adjustment flag on the
positioner used to create it that will cause the compositor to adjust
the position as the conditions used to constrain it change.

These changes may include, for example, changes in the position of the
parent window or the geometry of the work area. To allow the client to
update its content in response to the updated position, the client must
ack the configure event, optionally with new content. Until the client
acks this configure event, the existing positioner will continue to be
used.

Explicit popup moving is done using a new request on xdg_popup:
xdg_popup.move. What it does is change the parameters used for
positioning a popup by providing a new xdg_positioner object. This
request is coupled with a new event; xdg_popup.moved, sent together with
the configure events (xdg_popup.configure and xdg_surface.configure) to
notify about the completion of the move request. The move request also
takes a token that is later passed via the moved event; this is done so
that a client may determine for which move request the compositor has
sent configure events.

Both these methods by themself are racy regarding inter-surface
synchronization. In order to avoid race conditions when applying new
states, a new request is also added to xdg_surface:
xdg_surface.sync_with_popup. This request is a one-shot request to defer
application of the to be committed surface state until the state of the
passed popup surface is applied.

Lastly, a request to couple a xdg_positioner object with a configure
event is added in order for a compositor to pair a popup move request
with a pending configure event. This is necessary to, for example,
properly constrain a popup given a yet-to-be-applied parent state. An
example of when this may be necessary is an interactive resize where
both the toplevel position and the relative popup position changes.

For further explanation, for how it's expected to work, see https://lists.freedesktop.org/archives/wayland-devel/2019-July/040758.html

The corresponding GTK merge request: gtk!1017 (merged)

The first part of the merge request could potentially be split up, as it's more of a cleanup.