Codimension plugins subsystem.

Codimension plugins sybsystem is built on top of the yapsy library:
http://yapsy.sourceforge.net/ released under simplified BSD license.
So some terms (e.g. plugin category) and file formats (e.g. plugin
description file format) are borrowed from the library and their
description could be found on the library web site.



There are two places where codimension looks for plugins:
- system wide: /usr/share/codimension3-plugins/
  The system-wide plugins location is separate to the location of the IDE
  in order to simplfy plugins packaging for the developers
- user: ~/.codimension3/plugins/

Each plugin occupies a designated directory. The directory must reside at one of
the locations described above. The directory contains a plugin description
file with .cdmp extension and the plugin implementation files. The format of the
plugin description file can be found in yapsy documentation. Here is an example of
a description file:

[Core]
Name = Subversion
# The Module value must be '.'
Module = .

[Documentation]
Author = Sergey Satskiy <sergey.satskiy@gmail.com>
Version = 1.0.0
Website = http://codimension.org
Description = Codimension subversion plugin

The plugin directory must be a python package i.e. it must have __init__.py file.

There are no limits neither on the number of plugins nor the number of files in a
plugin directory.

Each plugin could be enabled or disabled. By default a plugin is enabled however
it could be disabled by the user or by codimension (if codimension detects poor
implementation or a conflict). If a plugin is disabled by codimension due to a
detected conflict then the user will be able to enable it when a conflict is
resolved.

Each plugin must provide information at least about its name and its version
(goes into a .cdmp file).
In case if the same name plugin is found both in the system wide location and in
the user directory then the priority is given to the user plugin and the system one is
automatically disabled. If the same name plugins are located in the system wide
directory or in the user directory then the priority is given to the higher plugin
version and the lower plugin version is automatically disabled.

Each plugin must belong to a predefined plugin category. Depending on the category
codimension expects a certain communication protocol.

Implementation wise a plugin category means deriving from a plugin category
interface class and implementing the required methods. A plugin from codimension
point of view is an instance of class which belongs to a supported plugin category.
The supported interface classes are located at
codimension/src/plugins/categories/ directory.

A plugin developer could follow the steps below:
- Create a separate directory for a new plugin with an appropriate name.
- Create a plugin description file .cdmp in the plugin directory and populate
  it with the appropriate information.
  Note: the [Core].Module parameter value must be '.' (without quotas).
- Make a choice of a plugin category by analysis of the supported categories
  at the codimension/src/plugins/categories/ directory.
- Create a plugin implementing class which derives from the interface base
  class. The implementing class must reside in the plugin __init__.py file.
- Implement all the mandatory interface class methods.
- The installation of the plugin is copying the plugin directory with all its
  files to a system wide plugins location or to the user plugins location.
  Next time codimension starts it will pick up and activate the new plugin.

Currently supported plugin categories:
- Version control system (see categories/vcsiface.py)
  Serves various version control systems e.g. SVN
- Wizard (see categories/wizardiface.py)
  Serves utility functions which could be run from the IDE UI or
  interfaceless utilities

Planned plugin categories:
- Exporter (see categories/exporteriface.py)
  Serves exporting buffer/file/directory/project content to another format
  e.g. pdf.
- Spell checker (see categories/spellcheckeriface.py)
  Serves spell checkers


