This only supports GTK at the moment, but it might be adapted to other toolkits.

Fix issue where having a maximized window on a second monitor, then that monitor gets removed which moves the maximized window to the main monitor, then restoring the maximized window would place it on a different viewport.  It should stay on the same viewport.

Yeah, again here... So, now when setting the window extents, we resize a window only in these cases:
1) We have a normal window that has never been decorated (lp:1282304)
2) We're (re)decorating a maximized or fullscreen window (lp:1282305)

This seems to work well in all the cases I tested, with no regressions with nedit
(that highlighted an issue with old code path)

1. Always set frame extents before updating the frame
2. Added COMPIZ_NO_CONFIGURE_BUFFER_LOCKS so that we don't have to deal
   with the delayed configure requests logic in the tests where it
   does not help
3. Split restoredDecorationSize in to restoredDecorationBorderSize
   and restoredDecorationInputSize so that we can measure the size of
   the decoration both in terms of its visible and invisible border
4. Wait for the default decoration properly
5. Capture the initial geometry of the window with and without decorations
   when the window gets its first decoration. Use these values to calculate
   the size changes in the window from then on instead of its creation
   values
6. Just flag when the window was first decorated in setWindowFrameExtents
   rather than checking if it is mapped. We only want to not resize
   the window once.

In the event that a window is unreparented or destroyed, we usually need
to add its frame window to the toplevel window stack until the time at
which we recieve a DestroyNotify for it, as there may be incoming
ConfigureNotify events puporting to stack other windows relative to
that frame.

However, this does not apply in the case where we have not yet received
a CreateNotify for the frame window. In that case, it is not possible
for any stacking requests to be made relative to this window, so it
does not need to be added immediately. Instead, we can add it at the
time that we recieve a CreateNotify for it as a regular override
redirect window until the time that it is later destroyed.

(LP: #1171314)

that variable only exists to track changes in the actual geometry of
the window and not the apparant frame extents.
  
Added tests to verify that behaviour.
  
(LP: #1138517)

It was causing a critical rendering regression (LP: #1089279).

It also caused a second strange regression where it was no longer possible
to safely revert 3513 (!?) without a causing a more severe regression of
LP: #1087193.

Issuing a ConfigureWindow request with a sibling parameter that refers
to a sibling that's actually destroyed server side results in a BadWindow
error, and causes what we might think is a correct ConfigureWindow request
to fail. This would cause even more problems because we had marked
the request as succeeding, and adjusted serverWindows appropriately,
which would cause further restacks to rely on the invalid internal state.

Unfortunately, this is effectively a race condition between the client and
the server. We receive our events and are racing the server to not
destroy the window internally before we get a chance to issue a
ConfigureWindow request relative to the destroyed window.

Because of that, we need to hold a server grab during the period in which
we check if the sibling window is still valid server side and when
we issue a ConfigureWindow request. If it is valid, then we can guaruntee
that the server will process the request relative to the sibling window,
and if not, we can select another sibling as appropriate.

Adjusted the API such that any function which looks for an appropriate sibling
or any function which calls XConfigureWindow with the sibling parameter
set requires a server grab to be active (by virtue of the fact that they
accept a const ServerLock &).

The only implicit contract between clients now is that the client must
obtain the sibling window either by using one of the designated functions
to do so which requires a ServerLock, or that the client holds a server lock
and while it holds the ServerLock, it calls XGetWindowAttributes or
XGetGeometry to check if the sibling window is valid.

configureXWindow was split into configureXWindow and
restackAndConfigureXWindow. The latter requires a server lock, the former
will warn about this potential race condition if you attempt to
restack a window using it.

Passing tests:

[ RUN      ] CompizXorgSystemStackingTest.TestCreateRelativeToDestroyedWindowFindsAnotherAppropriatePosition
[       OK ] CompizXorgSystemStackingTest.TestCreateRelativeToDestroyedWindowFindsAnotherAppropriatePosition (55 ms)

(LP: #1088399)

the other times

created above.

The server list might have been modified by the time that we process the
create event, and as such there is a case where a window can be inserted
into the server list above another window and not at the top (the default
for where windows are created) if that window is pending a restack.

When updateAttributes is called later, putting it above the correct window
will silently fail, because it is already there in the server list, even
though a restack was never issued to put it there.

(LP: #1008020) (LP: #886605)

 * CompWindow::move is now just a wrapper around CompWindow::configureXWindow
 * CompWindow::configureXWindow will always call through to moveNotify
 * moveNotify is only ever called pre-request to the server in the case of
   managed windows (SubstructureRedirectMask guaruntees they will end up in
   the right place) and post ConfigureNotify for override redirect windows
 * resizeNotify is always called post ConfigureNotify regardless of whether
   or not the window is managed or not
 * composite and opengl now use the geometry last sent to the server in order
   to compute display matrices and window positions as well as damage regions
 * decor now also does the above
 * const correctness in include/core/window.h
 * CompWindow::syncPosition is now deprecated and a no-op

not be recorded properly:

1. When determining restack requests relative to another window which is pending
   a restack, check to see if we already requested to restack relative to it
   after it was pending the restack, rather than unconditionally submitting
   the restack and risking that being a no-op
2. When a window gets closed, its frame window is marked "None" immediately
   so we must discard tracking of any remaining pending configure events
   as they wont come to the frame window as we know it
3. Remove the static timeout and replace it with a timer object that clears up
   any stale configure requests which didn't get matched to events (note that
   this will be removed, but exists only to safeguard against performance regressions
   with the current API)

Fixes LP#864330

track events based on request serial numbers.

The request serial numbers at the moment are the only reliable way of matching
events with requests that we made, so use them for matching. This means that
the number of non-matches is going to go way down. At the moment, we still
look at whether or not we got an expected geometry and stack position back
from the server in the window's pending request queue and if we didn't then
some plugin is messing things up and we warn about that.

Fix LP #866752

  server will actually obey, it is possible track outgoing ConfigureWindow requests
  and match them to incoming ConfigureNotify events, assuming that priv->geometry
  and priv->serverGeometry ONLY represent what was last sent to the server and what
  was last received. Which allows us to effectively fix the race conditions
  which made positioning and stacking unpredictable at times.
  
  As such, any plugins past this commit, need to be careful not to modify w->geometry
  or w->serverGeometry directly. Unfortunately, the move plugin is a serial offender in
  this area and will update w->serverGeometry directly after doing w->move, which causes
  race conditions when other plugins try to configure a window through the server first.
  
  This change ensures that when there are pending ConfigureNotify events, no synchronous
  updates of the window geometry are allowed. For plugins that do touch w->serverGeometry
  for whatever reason, a lock_geometry call is sent through handleCompizEvent whenever
  there are pending ConfigureNotify events for plugins not to do that. This will remain
  in place until we can break ABI/API and prevent plugins from doing that.

By doing this we are able to see what the pending requests are on a window
at any given time, and can transform new requests to suit these pending
ones. Currently, this only works for windows that we reparent and are
not override redirect since those are the only windows where we can guaruntee
that all ConfigureNotify events will be generated by us.

This isn't exposed to plugins at the moment, but it may be useful later on.

Incidentally, this allows us to fix a stacking corner case which was the
following situation:

Windows A, B and C map (placed on top), and must stack relative to each other

Window A gets stacked beneath D (which is a panel),
Window B should be stacked above A,
Window C should be stacked above B,

What happened was that updateAttributes would be called and
request to put window B above A, which it was already above in
CompScreen::windows, so that stacking request becomes a no-op. In this case
we check if the window is pending a restack and then request to put it
above the same window it was already a sibling to if findSiblingBelow found
that to be the case.

This fixes problems with, eg GIMP and Libreoffice, which make heavy use
of transient windows when mapping their windows and may also restack
their own windows when there is no window manager running

   * Only update frame regions when we get an event that something changed
     server side (eg don't immediately update the region once we issue
     a ConfigureWindow request)
   * Keep track of the changes in the input extents
   * Ensure that a synthetic ConfigureNotify is sent in cases where the resized
     frame window will exactly match its last size such that the client is
     positioned correctly inside the frame