Work around Mali use-after-free upon window resizing

Two quick successive resizes of the LibreOffice Writer window under
gnome-shell results in momentary visible corruption.

Inspecting the stream of events, it seems that two successive resizes
with `xdotool windowsize --sync` causes 5 flips to happen. Flip number 2
has bad data. In between flips 1 and 2, Mali asks us to destroy the DRI
buffer backing the window size at first resize, then it calls
CreateBuffer on the window drawable at its second resize, then
ScheduleSwap. Suspicious that it frees the previous window buffer so soon.

We discovered that delaying the freeing of the buffer that we were asked
to destroy makes the corruption go away. Looks like Mali has a
use-after-free bug.

We try to work around this in a simple way: we now delay all bo frees
until the next ScheduleSwap. We've done a few tests to confirm as best we
can that ScheduleSwap is indeed a reliable indication from Mali that it
has finished drawing the scene. This workaround works for the mutter case,
but is likely to fail on multi-display setups, complicated compositors
that render more than one flip in advance, etc.

Thanks to Vincent Sanders and Daniel Stone for help understanding this
issue.