Revert "Add QT_WAYLAND_COMPOSITOR_NO_THROTTLE"

This reverts commit 8421e5b8b160d7f31adeafab7225cc5e4b7467c7.

Minimize the delta between upstream qtwayland and our internal one.

Throttling should be done by discarding frames in surface_commit, but
releasing them direclty. This is less intrusive on the rest of the
compositor logic.
Revert "Immediately send frame callback on detach"

This reverts commit 6cf69e8ed0600a510c6fed2ec886e58b4f49e022.

Minimize delta between upstream and our stuff.

It is wrong to trigger the sendFrame logic at this time. This
code is called from commit() which is disconnected from the
frame rendering.
Revert "Don't disown() buffer until a new texture id is requested"

This reverts commit af3b94e76278f0c94ca146c7aab816073145cd6f.

Minmize delta between upstream qtwayland and mer.

This imposes another update/sync which leaves the client with
significantly less time to complete its next frame, a period
in which the compositor holds two buffers.
Fix buffer handling.

The surface now has a distinct back and front buffer. Front means it
is on the screen and being used as a texture. Back means it should be
put to screen in the next updatePaintNode().

For the purpose of QML and GUI-thread properties, the 'back' buffer is
what contains the correct properties as it is what it will eventually
be rendered with. For the purpose of rendering, the front buffer
contains the right texture. If no back buffer is present, then there
was no changes and front buffer applies to both.

The Surface's buffer queue has been updated to only fire damage and
advance once we swap back buffer to front buffer which happens during
updatePaintNode(). The fact that the buffer advancing happens during
sync also means that we are releasing buffers back to the client as
soon as another buffer is ready to be displayed in the
compositor. This is "half a frame" earlier than in upstream qtwayland
(which releases after the next swap). We consider this safe because:

 - The compositor has a new buffer to display and does not need the
   old one.

 - If the GPU is not done rasterizing the scanout buffer for the
   previous frame, there should be a read-lock on the buffer so if the
   client tries to render to it, it should block. If this assumption
   fails on any hardware we can make the time of buffer-advance
   optional. Either during "sync" or during "after rendering" as it is
   today, but "after rendering" will not offer any guarantee, just
   more time, resulting in a higher chance of the buffers being
   ready. Aka, without an internal read-lock, there is no guarantee.

Texture cleanup is now explicit as we have a well defined location
to clean up textures, during updatePaintNode(). This avoids cleanup
issues which previously existed as buffer cleanup was happening on
the GUI thread.

The change also removes doUpdate, postBuffer and frameSwappedInternal
as these are no longer used. Direct rendering will need to be
considered in a new light with the new buffering scheme, and anyway
needs work.

Before this change can be upstreamed, we also need a way to advance
the buffer queue from the widget and window based compositors also.