Plugin revision API
dr
Coming up on the second main release of Kismet-Newcore based code, I've realised that
plugins lacking a revision control (version matching plugin to binary) was a major
oversight and could lead to massive problems (plugins being compiled against an old
version of Kismet are very likely going to crash a newer version, if they even load).

Not wanting to break existing third-party plugins, a new revision api has been added.
If the function kis_revision_info(...) is present, a plugin is expected to return version
info from when it was compiled.

To allow for future expansion, the revision info struct contains a version field which,
when passed to the plugin, indicates what revision struct Kismet allocated, and when 
returned, indicates what version the plugin can handle (ie, a future Kismet release may
include binary checksums or somesuch for versioning, and pass revision 2, but a plugin
which only checks against revision 1 would set this and return).

Almost every plugin will have the same kis_revision_info function:

<pre>
	void kis_revision_info(plugin_revision *prev) {
		if (prev->version_api_revision >= 1) {
			prev->version_api_revision = 1;
			prev->major = string(VERSION_MAJOR);
			prev->minor = string(VERSION_MINOR);
			prev->tiny = string(VERSION_TINY);
		}
	}
</pre>

Third-party plugins should update to include this function so that they can be 
version-checked before loading.  Plugins which don't include this will still be loaded,
but with warnings that they may be unreliable.

This revision API is only as granular as the Kismet release.  Users tracking the SVN 
development tree will have to rebuild plugins whenever something acts weird (or whenever a
svn update is done, to be safest).  Some future plugin tracking mechanism might handle this,
but honestly it would be a big pain for users and for me so it'll probably stay at the 
release-level control.