To reduce the boilerplate code needed for each plugin, the PluginBase
class now pulls out the plugin's options from the configuration object.
They get stored under the reasonably obvious name of ``options``.

Now the Kaylee object handles the invalid_sentence_command as well.  It
does this by having the last handler for the recognizer's 'finished'
signal.  If this handler is ever run, the voice command was obviously
not wanted by any of the plugins, so the invalid_sentence_command should
be run.

Also, I fixed the UIs to work as before.  It's a temporary fix!

The plugins shouldn't be in charge of running the
valid_sentence_command.  They also certainly shouldn't have to manage
the history file.  Both of these functions have been delegated to the
Kaylee object, by way of a 'processed' signal emitted by a plugin as
soon as it knows it will handle the voice command.

Since Kaylee now supports Python plugins that can do arbitrary things
with spoken words, the pass_words option for shell commands seems
somewhat less necessary than before.  I never liked it in the first
place, because it was all-or-nothing: there was no non-hackish way to
pass the spoken words to only specific commands.  If I ever see a
compelling reason for this feature to come back, it may be
re-implemented in the form of a second shell plugin that passes words to
its commands.

As part of the effort for resolving #12, I've started work on a plugin
API for Kaylee.  While very much a work in progress, it will allow
Python plugins to be written, loaded from user configuration, and
hooked in to events from necessary portions of Kaylee to handle voice
commands.

Currently there is only one plugin, a partial implementation of shell
command support as existed previously.  It works in that it executes
commands, but several old features are missing.  Also, the GUIs are
probably broken, but I'm not worried about that at the moment.