Merge pull request #374 from cprice-puppet/maint/master/cherry-pick-1.0.5-stuff

Maint/master/cherry pick 1.0.5 stuff
Acceptance: better method of checking target schema version

This commit adds a very simple command-line program, 'version',
which returns some data about the PuppetDB version.  Currently
it only returns the main PuppetDB version string and the target
schema version, which is useful for testing purposes.  Would like
to add some additional info (database name/version, etc.) in the
future.
Update docs to reflect that the output is no longer JSON
Add command-specific spool config settings

This commit only modifies the configuration settings code.  It
allows the definition of new `[facts]`, `[catalogs]`, and
`[reports]` settings in the `puppetdb.conf` file.  Each of these
sections supports a boolean setting named `spool`; these settings
will be used to control whether or not PuppetDB commands are spooled
to disk before submission and retried after failures, but this
commit does not implement that functionality yet.

The default for the `spool` setting is `true` for reports, and
`false` for catalogs and facts.
Reorganize Utils::Puppetdb module a bit

This just makes sure that the correct methods are public/private
and groups class vs. instance methods appropriately.
Add support for retrying commands

This commit adds the logic (and tests) for spooling commands to
disk and retrying them later if they fail.
Refactor: introduce Command class

This commit moves all of the logic about commands (formatting, spooling)
into a new class called Command.  This way, the main "PuppetDB" util class
only needs to contain the logic about submitting / flushing the commands.
Better separation of concerns, and tests are able to focus on more atomic
business logic.
Refactor: create Config class

This commit breaks all of the configuration-related logic out of
the 'util/puppetdb' class and puts it in a new class called `Config`.
This is a better separation of concerns and makes the test files
for the two classes a little easier to read and maintain.
Add a maximum number of failures to the flush_commands method

In cases where PuppetDB has been down for an extended period of
time, you could end up with a large number of commands queued for
delivery.  Without some kind of maximum retries limitation, then
as long as PuppetDB remains down, every agent run that comes into
the master would cause PuppetDB to retry every single command that
was still in the queue.  Depending on how quickly the attempt to
connect to PuppetDB times out, this could cause huge performance
issues on the puppet master.

This commit adds a failure limit (currently hard-coded to 3) to
the command flushing logic.  Thus, if we try unsuccessfully to
flush 3 queued commands to PuppetDB, we'll stop trying until
the next time a flush is triggered.

Eventually we may want something even a bit more sophisticated
than this; this implementation will still cause 3 attempts on
every single agent run for the duration of the PuppetDB downtime.
We could build on this implementation by capturing a timestamp of
the last time that we encountered the maximum number of failures,
and don't retry again for a certain amount of time (5 minutes?)
after that.