Fix _NET_WM_FRAME_DRAWN timestamps

Same as !1360 (merged) but for master (and 3.38).

    compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scope
    
    The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
    resolution X server timestamps", meaning they should have the same scope
    as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
    the same time.
    
    This was not done correctly when mutter had determined the X server used
    the monotonic clock, where it'd just forward the monotonic clock,
    confusing any client using _NET_WM_FRAME_DRAWN and friends.
    
    Fix this by 1) splitting the timestamp conversiot into an X11 case and a
    display server case, where the display server case simply clamps the
    monotonic clock, as it is assumed Xwayland is always usign the monotonic
    clock, and 2) if we're a X11 compositing manager, if the X server is
    using the monotonic clock, apply the same semantics as the display
    server case and always just clamp, or if not, calculate the offset every
    10 seconds, and offset the monotonic clock timestamp with the calculated
    X server timestamp offset.
    
    This fixes an issue that would occur if mutter (or rather GNOME Shell)
    would have been started before a X11 timestamp overflow, after the
    overflow happened. In this case, GTK3 clients would get unclamped
    timestamps, and get very confused, resulting in frames queued several
    weeks into the future.