clutter/frame-clock: Use update time estimate in want_triple_buffering

We don't want triple buffering when the estimated maximum update time is
known and no larger than a refresh interval. In that case, regular frame
clock dispatch is scheduled after the previous frame is presented, so no
third buffer is necessary.

Allowing triple buffering anyway was problematic when frames are skipped
for reasons other than the frame update taking too long (e.g.
https://gitlab.gnome.org/GNOME/mutter/-/issues/3884):

1. First frame dispatches, targets display refresh cycle (DRC) n, but
   skips
2. Second frame dispatches, targets DRC n+1
3. First frame is presented at DRC n+1
4. Second frame is presented at DRC n+2

Without triple buffering:

2. First frame is presented at DRC n+1
3. Second frame dispatches, targets DRC n+2
4. Second frame is presented at DRC n+2

The second frame is presented at DRC n+2 in both cases, but with triple
buffering it targeted n+1, i.e. its contents might not be consistent
with when it's presented.

It gets worse with triple buffering if the second frame also skips:

4. Second frame skips, is presented at DRC n+3

That's a discrepancy of 2 refresh cycles between the target and
effective presentation time, which might be noticeable as more severe
stutter.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4282>

clutter/clutter/clutter-frame-clock.c

@@ -1029,10 +1029,17 @@ clutter_frame_clock_uninhibit (ClutterFrameClock *frame_clock)
 static gboolean
 want_triple_buffering (ClutterFrameClock *frame_clock)
 {
+  int64_t max_update_time_estimate_us;
+
   if (G_UNLIKELY (clutter_paint_debug_flags &
                   CLUTTER_DEBUG_DISABLE_TRIPLE_BUFFERING))
     return FALSE;
 
+  if (clutter_frame_clock_estimate_max_update_time_us (frame_clock,
+                                                       &max_update_time_estimate_us) &&
+      max_update_time_estimate_us < frame_clock->refresh_interval_us)
+    return FALSE;
+
   return TRUE;
 }