Merge lp://qastaging/~compiz-team/compiz-core/compiz-core.stack_sync_fix into lp://qastaging/compiz-core/0.9.5

Fixes some of the problems in bug 845719

Changes
1) Push destroyed windows into a separate tree which plugins can query in case they are holding references to them rather than keeping them in screen->windows () where they will only server to confuse the stacking code in the case of xid conflicts.
2) Use a separate serverWindows and windows in order to calculate pending restacking operations on windows last sent to server and last recieved from the server, rather than immediately restacking the window list and running the risk of having a ConfigureNotify come back and be processed relative to the stacking operation that was not in sync with the server and thus be invalid
3) Grab the server and directly query the tree whenever issuing synethetic ConfigureNotify events such that they will always be emitted relative to whats on the server rather than a half-complete version of what was last received from the server
4) Remove dead code
5) Wait for the server to issue a CreateNotify event for frame windows before adding them to the tree so that ConfigureNotify events that come before the CreateNotify event are not processed in an invalid way
6) Immediately remove windows from the window list on DestroyNotify
7) Ensure that we initiate all windows directly after querying the tree on startup to avoid race conditions where we will never receive a CreateNotify event for windows that are changing their state during a compositor or WM restart
8) Manage windows from top to bottom on startup
9) Don't force restack windows since the stack is already correct when we've managed all windows
10) When processing DestroyNotify events remove the client window from the list and create a CompWindow for it's frame as that has not been destroyed yet and we may receive ConfigureNotify events from previously processed ConfigureRequest events that are relative to the frame. It is safe to remove that CompWindow once the frame receives a DestroyNotify
11) Do not immediately update the last received stack on reconfigureXWindow
12) Added stack sync debugger object
13) Added stack sanity debugger object
14) Do not destroy window frames, instead keep them around in a separate map and unmap them (but keep them in the stack since clients may want to restack relative to them). When the withdrawn window is mapped again put it back into the same frame (keeping the frame below the client) (NB: This is a bit of a weird solution, but it works and might be something that we want to come back to later).
15) Process CreateNotify events relative to the last last recv from the server

Stuff that needs fixing
=======================

Apparantly firefox stacking can still go a bit wonky
We need to check the stack sync on Create and DestroyNotify events

Debugging Plan:
===============

I did the necessary changes in core to ensure that the stack you'd get if you grabbed the server, did XQueryTree, and then queued all events and ungrabbed the server at the start of PrivateScreen::processEvents would be exactly the same as the "last recieved from server" stack at the end of PrivateScreen::processEvents after processing ConfigureNotify events for windows which have had their stack positions updated.

As such, we can now reliably debug and warn when the stacks go out of sync. If you run with --debug, core will do XQueryTree at the beginning of each ::processEvents and compare that stack with the results of screen->windows () at the end of processEvents. If there is a mismatch, it will warn. A flag can also be changed in the code (specifically, StackDebugger::cmpStack (windows, serverWindows, verbose = false)) to enable a full readout of each stack, and indications of where there are mismatches. You can easily put a breakpoint there to trace which sets of communication/response are causing problems.

The other kind of stacking bug is where data is sent and received from the server correctly, but the stacking order sent to the server is not correct as defined by the Extended Window Manager Hints [1]. Though there are some omissions in the standard, the expected stacking order is from top to bottom:

 - 1) Docks stacked above toplevel windows which are stacked
      above fullscreen windows
 - 2) "Keep above" toplevel windows above fullscreen windows
      where a toplevel is in focus
 - 3) Toplevel windows in focus above fullscreen windows
 - 4) Fullscreen windows
 - 5) Dock windows
 - 6) Keep above windows
 - 7) Toplevel windows
 - 8) Docks which are marked "Keep Below"
 - 9) "Keep Below" windows
 - 10) Desktop windows

 There are also a few rules which apply here:
 - 1) Dock windows should always be above normal windows
      except if marked keep below on any layer.
 - 2) Dock windows should ONLY be on one layer at a time,
      eg if they are on layer 1 then there cannot
      also be dock windows on layer 5 (except in the
      case of below dock windows on layer 8)
 - 3) Fullscreen windows must always be above docks when in
      focus, no matter if there is another window with "Keep Above"
 - 4) Focused windows take priority over fullscreen windows and
      docks must always be above them (see rule 1)

The code in StackDebugger::checkSanity will check the outgoing stack to see if it matches these criteria, and if not, it will warn when doing so. In the vast majority of cases, I've found that this works fine, but there are a few edge cases where it still warns and there are visible errors (eg, with a Keep Above window and 2 Toplevels above a fullscreen with docks above them, grabbing one of the toplevels will place it below the fullscreen window, which is incorrectly).

[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER