We keep resources saved in resourceManager as CompOption, if anything cursor
related changes we emit a cursorChangeNotify

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.

methods don't have virtual destructors, added the virtual destructors to
get rid of warnings and potential memory leaks

Use prefix instead of postfix de- and increments

PluginClassHandler::get () was designed to simply instantiate an instance of that
class for the core structure, but it did this without checking if the plugin was
loaded.

Added some new methods to PluginClassHandler exposed by LoadedPluginClassBridge
and only accessible by those who implement PluginKey to specify globally
whether or not a plugin is actually loaded, so that PluginClassHandler can
return accordingly.

Integration and unit tests added as appropriate

(LP: #1169620)
(LP: #1101026)

and all calls to it

Commented out calls to syncPosition in group plugin

in compiz

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)

1. Have compiz send a dedicated startup message so that we don't race 
it to check that a PropertyNotify was sent before it grabs the server
(since the grab position changed)
2. Fix event advancing semantics in the tests - only go to the next event
either if a) the user asked for it or b) the event didn't match
what the user wanted. Advancing even when it did match messes up
the case where matcher chain on each other

  which will invoke the destructor for the Glib::Source.
  
  Added an integration test to prove it
  
  (LP: #1085590)