Introduce run-time loaded modules

[KristianLyng]

With the plugin package, we can do traditional dlOpen() type module loading, which would solve a number of maintenance problems, particularly for things like protocol buffers, where potentially large bulks of code need to be (re-)generated to track hardware/firmware changes, but the code is otherwise the same. It also allows us to isolate libraries with unreasonable dependencies into separate packages.

Looking at it, I think the basic scaffolding we got should work well. Some minor things though:

Modules access sender.Auto directly today, this might(!) not be possible. This can be easily solved by extending skogul.Module to include a type, for instance, and requiring modules to implement something like GetModules() []skogul.Module.

This will not require a great deal of code, but it will take some time because this is an area where ensuring the API is stable is absolutely crucial. Luckily, the Interfaces we've used so far have proven to be stable, so that's good, so it's mainly initialization that's sensitive.

Also, this makes documentation more interesting, but that's a fairly easily solved problem. Off-tree modules would still self-document the same way as always, but that would obviously not become part of the pre-generated manual file. Since we don't want to introduce a run-time dependency on rst2man, re-generating a man file isn't an option either, so I figure we start with just some run-time commands to print the documentation to std somewhat nicer than we do already with ./show. That's particularly sensitive, since it can be easily adjusted as we gain experience.

An other task to solve would be where to install and look for modules. Lacking a global config file, I see a new config option in our near future.