As described in issue #16, commands are now processed in two stages.
First, all plugins get to give a confidence with which they are the
right plugin to handle the command.  Then, the one with the highest
confidence gets to run first, and if for some reason it can't handle the
command, other plugins try in turn.

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.

Recognizer.commands was unused, so there's no reason to keep it.

Apparently CMU thinks it's a good idea to release a new version of a
piece of software that breaks existing APIs without even changing the
version number.  I find this idea to be highly dubious at best.
Nevertheless, I have updated Kaylee to support the latest version of
pocketsphinx.

That's "Kaylee Voice Command" if you didn't figure it out.  I think
everything still works properly, but I'll do more testing later to
verify.

Now we check a hash of the voice commands before writing the strings
file to reduce how much we write to the hard disk.  In implementing
this, I realized that some code was being duplicated in an easily
fixable way, so I created a Hasher object that keeps track of the
hash.json file.

Resolves #6

See commands.tmp for an example.  It's pretty neat, but it could still
use some work.  I thought of a really clever way to parse numbers, better
than the one I came up with last night, but since I have a working
implementation now I figure I'd better commit it.

We have a new bug which causes the dictionary to be updated every time the
program starts.  I hope I didn't force that to happen last night or
something, but I have a vague feeling I did.

Paths of important files and directories are part of the program's
configuration, no?

We're making better use of XDG paths now.  Only configuration-y things
go in $XDG_CONFIG_HOME now, with cache-y and data-y things going in the
appropriate places instead of just being crammed in with configuration.

Removed a bunch of print statements that looked like they were added for
debugging, then never removed.

Reorganized GStreamer pipeline code so that all configuration is done
when the pipeline is created.

The configuration file is now properly overridden by argument parsing.
This was accomplished by loading the config file, then treating the
specified options as a namespace for the ArgumentParser.  This makes
things from the config file get overridden iff they were specified on
the command line (not simply from defaults set in the ArgumentParser).

Mostly working for the options file now.  Still some difficulty with
command-line arguments, though; they're overriding the config file even
when not specified.  If I made them simply not get stored at all when
not specified, there would be further problems when a configuration file
is not present.  Maybe I should make a whole new class to handle this.

We now have a hash.yaml file which contains a SHA256 hash of
sentences.corpus.  If this differs from the hash the file calculated
when Kaylee sarts, the language is updated and the new hash is stored in
hash.yaml.

I'm a GTK man myself.  I don't know if I have Python QT bindings
installed on any of my computers.  It follows then that I would not
maintain the QT interface well, let alone use it at all.  It has
therefore been removed to avoid having someone try to use it only to
find that it's broken.

Gotta keep that stuff up-to-date, yo.  Pocketsphinx changed so it needs
GStreamer 1.0, and that required rewriting everything to use GObject
Introspection instead of the old, static Python bindings for GObject.