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 the current implementation (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, it should hold a read-lock on the buffer so
   preventing the client from starting a render to it. 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 and no
   fence mechanism, 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. Surface and Buffer destruction coming over wayland is
queued up in compositor and handled before the next "sync", when it is
safe to do so.

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.

Change-Id: I2db0385b4b8859f96caba374f3530448178e1473
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>