Code review comment for lp:~afrantzis/mir/client-surface-buffering-mode

It might be more flexible to just let the clients acquire more than one buffer at once, and then the clients just submit the buffer that they last-generated to the server for it to use.

Advantages:
* Gets us a bit closer to server-or-client-allocated buffers (as opposed to our server allocated buffers nowadays)
* This diffuses the density of the logic in BufferQueue a bit, as the client shares in the responsibility of how the flip chain works.
* The server doesn't even have to know if the client is running in swapinterval 0 or not, it would just have a last-submitted buffer.
* Nested-passthrough can use the normal BufferQueue, instead of dancing around the limitation that it can only get one buffer at a time.
* nested becomes an normal platform, as it has a way to allocate a buffer.
* we don't have to hash out what "double" and "triple" means exactly in the client api.