Migrate to a separate "command" class

Commands were previously defined with a trivial DSL in the app.rb file, which
worked reasonably well while we had a fairly small and simple set of commands.

With the addition of a validation framework, though, this began to get
cumbersome, and as we extend the set of features that are "about" commands,
rather than commands themselves (eg: help, documentation, browsing), this
becomes harder and harder to keep sensibly structured.

The goal of this series of changes is to move away from a single file
definition into something more, well, OO-based: a single class per command,
defining the basic behaviour of an individual request.

This also allows us to attach metadata about the command to the same place,
such as schema definition for validation, help generation and text, and
so forth.

https://tickets.puppetlabs.com/browse/RAZOR-179

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Validate `move_policy` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `add_policy_tag` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `remove_policy_tag` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `modify_policy_max_count` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `update_node_metadata` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `remove_node_metadata` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Validate `modify_node_metadata` command.

https://tickets.puppetlabs.com/browse/RAZOR-178
Implement help text DSL for commands

This adds a new DSL for defining help text on commands.  The `summary`,
`description`, and `examples` commands at the class level attach parts of the
documentation to the command object itself.

While these presently allow us to attach the documentation and provide no
mechanism to communicate it to the user, they are the basis for building that
facility and allow us to work in parallel on building and presenting the docs.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Schema and model class for the command log

The command log will allow us to both store an audit trail of commands
issues against the server and use those commands to report status and
errors of background jobs connected to specific commands.
Add logic for creating (starting) and finishing commands
No functional change - remove trailing whitespace
Have all commands add an entry to the command log

Any successfully submitted command will now create an entry in the command
log, and the command specs check for that. For now, all commands will
pretend to be synchronous, and report a status of 'finished' when the
corresponding request ends.
Update command status for background tasks

For ISO import, we thread a command object through to the message
processor, tkaing care to pass it along to each stage of the import
process. The import process then updates the status of the command, in
particular marks it as 'running' as soon as it starts working on it, and
marks it as 'finished' when the last step of the import saga is done.

Most of the error reporting is done by our message processor - that is
crude, and better ways to report errors from within the actual processing
is the main reason why we try to pass the command to each stage of the
saga.

We can't demand that all background tasks have a command associated with
it: changing node metadata and tag rules spawn background jobs in
Node.around_save and Tag.around_save, where they do not have access to a
command object, nor does it seem desirable from the user's POV to treat
them as async commands. There may be a case to give the user an indication that the database has settled after these changes, but that is unlikely to change the general situation that we'll have background work that is, to the user, part of their command, and some that isn't.

The way the command is threaded through all over the place is a bit clumsy;
an alternative would be to have the messaging plugin define a 'command'
method that returns the command associated with the operation if there is
one, and methods that are called during async processing can access it that
way to e.g. report errors or update the status
Add a command collection to the API

Provide the standard means for listing all commands (in descending order of
submission) and to get the details about a specific command.

This commit finishes the fix for https://tickets.puppetlabs.com/browse/RAZOR-7