Pluginbase as object (version 2)

[flynd]

plugin.

The exported structure contain a pointer to a factory function the PluginManager can call to create a plugin instance. The plugin instance must inherit from either Licq::GeneralPlugin or Licq::ProtocolPlugin which specify the interface for communicating between the plugin and Licq as well as other plugins. This inheritance allows future extensions to the plugin interface to be made without having to export additional symbols.

This should also allow plugins to communicate directly with each other. For example, if a protocol plugin has a public header file, a GUI plugin could cast the plugin pointer to the protocol plugins type and access additional features not supported by the Licq daemon. (This might be a way to simplify the separation of the ICQ protocol from the Licq daemon without adding generic support for all ICQ specific features.)

The exported structure also contains the Licq version the plugin was built for. Plugin loading is only allowed if the Licq version matches with the daemon. This should catch differences between the plugin and the api that could lead to strange behavior or crashes. It is assumed that the last digit in the version is only used for minor releases that doesn't change the api and plugin loading will be allowed between for example 1.6.0 and 1.6.2, but not between 1.6.0 and 1.7.0.

Changes from previous branch:

• Parameters for Plugin constructor are wrapped to not expose the parameters and internal datatypes in the public headers.
• Plugin data includes a reaper function that makes plugin objects be deleted from the plugin library.

[erijo]

Besides maybe doing something about the friend declarations for the test classes I say merge it.