Address some long term problems with SurfaceStack's synchronization...
1) SurfaceStack was a BasicLockable, requiring a recursive_mutex. 'locking' the surface stack would just lock the ordering, it wouldn't lock the surfaces contained by the surface stack. Eliminate lock()/unlock() from the mc::Scene interface
2) The decisions the compositor made were based on data that was potentially stale when it came time to apply the decision. That is, every time the DefaultDisplayBuffer compositor went to access something from the BasicSurface, it could get a different value back, and had no way to lock the values (eg position) until the render was complete

A few ideas were examined:
A) locking the surface ordering and the surfaces
This has the disadvantage that we essentially have one big lock around the central data structure of mir
B) locking the scene, and copying the surfaces
This has the disadvantage that the buffer acquisition (compositor_acquire) has to take place sooner in the render, leaving the client less time to sneak its buffers in to make the next frame posting
C) locking the scene, copying the surfaces, and lazy-copying the buffers.
This is the approach proposed, as it freezes the positioning info for the surfaces at generate_renderables_list() time, but allows the clients to sneak in 'last minute buffers' and make an earlier frame if they return their buffer between "generate_renderable_list() and when the GLRenderer needs the buffer for texture reasons. The positioning info is just locked during the copy, so the rest of the system can proceed with what it has do (servicing move requests, rearranging the surfaces, etc) while the compositor is drawing.

Approved by PS Jenkins bot, Alexandros Frantzis, Alan Griffiths, Alberto Aguirre.