Merge lp://staging/~compiz-team/compiz/compiz.performance_1027211.2 into lp://staging/compiz/0.9.9

Allow plugins to throttle delivery of ConfigureWindow requests within reason (LP: #1027211)

Allow plugins to throttle delivery of ConfigureWindow requests within reason (LP: #1027211)

(LP: #1027211) seems to be caused by vsync in the nvidia driver and posting lots of ConfigureWindow requests to the server. The driver really chokes on these for some reason. As a result, two things were happening:

1. The driver slows down quite significantly
2. We get more time to post more ConfigureWindow requests to the driver, which just slows it down even more until it grinds to a halt.

This branch does three things:
1. Introduces infrastructure for plugins to hold a "lock" on delivering ConfigureWindow requests until they choose to release it later (eg, on paint, or on ungrab), while still allowing core to override the plugin's decisions in cases where we actually need to post a ConfigureWindow request to the server in order to continue (eg, some other request is dependent on it). That code was TDD'ed into existence and has test coverage.
2. Optimizes reconfigureXWindow to only configure the frame window if the only thing that happened was that we moved the window. This means that we only buffer up one ConfigureWindow instead of three per call to reconfigureXWindow
3. Implements ConfigureRequestBuffer in both opengl and move. The default implementation in "opengl" is the "safe" version and releases its lock every time the window paints. That means that dragging around opengl rendered windows goes from a complete halt to a steady 12fps. In the move plugin, I've revived "lazy positioning" - off by default as it might be more unsafe, but this prevents all ConfigureWindow requests from being posted until the window is ungrabbed. That goes brings us from 12fps to 60fps.

One question that might arise here is whether or not this branch is fundamentally unsafe because we allow the server to get "out of sync" with us. That isn't as much of a problem these days as it used to be. Nowadays we never track the incoming positions from the server to give us a representation of our own internal state, instead that is represented by what we meant to post to the server. So the internal state can never get mucked up. In areas where we do actually need to have our internal state represent what was really last sent to the server, I've structured the code such that in order to do those things, you have to release the queued up ConfigureWindow requests first.

Again, throw this at the wall and see if it introduces any bad regressions. I haven't see any so far.