1. Completely remove decorOffsetMove and other related code from
   decor.cpp. Put the logic to handle the window->input () - window->border ()
   placement offset inside of setWindowFrameExtents instead. Now the window
   will always be offset from its original non-decorated position to the new
   decorated position, rather than having to guess between decoration sizes.
2. Make saveGeometry and restoreGeometry work relative to window->border ()
   as opposed to including it in the saved geometry. It is possible that the
   border size might change during maximization, as such, we don't want to
   save the position with the border before maximizing. Instead save the position
   as if it were never decorated so that when the window is restored it can be
   restored to its original position and then adjusted for its new border size.
3. Fix a few typoes in the tests.
4. Moved some commonly used matchers into compiz::testing
5. Make COMPIZ_PLUGIN_DIR accept multiple directories and look in each one
   of them for the plugin
6. Set COMPIZ_PLUGIN_DIR appropriately for each plugin that we wish to load
   on startup so that we load locally built plugins as opposed to installed
   ones.
7. Uncomment compiz_discover_tests for the acceptance tests. Now they are
   run by default.

the plugin

(LP: #1193596)

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)

its only caller (availablePlugins) is now also removed.

Re-implement the small part of the dbus plugin that used availablePlugins()
to use getPlugins() instead.

availablePlugins is unused except by dbus, and flawed by designed. It makes
no sense to have a function that claims to return the list of available
plugins, when that list is not complete. You could easily load other plugins
from LD_LIBRARY_PATH that availablePlugins doesn't know about. And you could
add or remove plugin binaries at runtime which would also invalidate what
availablePlugins knows.

If you want a list of known plugins, call CompPlugin::getPlugins() instead.

loading/unloading/starting/stopping etc.

(attempt #2: Now passes test cases added since v1 of this branch)

loading/unloading/starting/stopping etc.

of waiting till run-time and allowing them to cause a crash. (LP: #938478)

destructor, since plugins that make copies of CompOption::Value can cause actions to
be added through setOptionForPlugin and then those actions will be removed when the
value temporary goes away.

The action adding and removing only happens within the bounds of CompOption anyways, so
its its more appropriate to have it in its destructor.

Of course, this brings up another issue, which is that CompOption should be noncopyable
but this opens up a whole another can of worms.

How this even worked before is beyond me...

LP #931927