Plugin versioning

Plugin system should allow multiple plugin versions at once.
This could be achieved by implementing interfaces as virtual classes with version number in their declaration and appending next versions in interfaces headers. This way the plugin version would have to be checked at least during initialisation and perhaps also while drawing. If so, the overhead introduced by checking the plugin version mustn't be large. One way to speed up the check would be either a) caching the version number instead of casting b) starting check with most recent versions.
Perhaps each interface could be sub-classed from a common ancestor providing some common methods. Yet again, this could introduce some lag.

[2010-08-15]
Plugins are considered to be versioned per carto release since Plugin interface provides more like meta-data information along
with list of features available (which is specific for a release). If a particular release contains new features then any already
existing plugin will not support them unless recompiled. But it will be compatible with current release and backwards.

Versioning of the BrushInterface would be maintained separately including full backward compatibility.

brushinterface and backward compatibility concepts:
1. interface hierarchy.
BrushInterface as a root. Any new modification as an extension to a BrushInterface.
sample: BrushInterface, BrushInterfaceV2 extends BrushInterface, BrushInterfaceV3 extends BrushInterfaceV2

2. All versions of BrushInterface keept in seperate spacenames. Application must keep track of
all namespaces and use a specific one for a given brushinterface version

3. BrushInterface is an incremental interface without any modifications allowed to already declared methods.

[2010-08-16]
No backwords compatibilty for the time being.