Add positional types to Razor::Matcher#validate

This extends Razor::Matcher#validate to accept different argument types for
different argument positions. This will allow the `fact` operator to take in a
String for the fact name followed by a mixed type second argument that would
serve as the 'fact-not-found' default return value.
Define failure semantics for `fact` operator

Defining `fact` to match or raise an error prevents matching failures because
of typos or incorrectly named facts. Allowing a second, default argument for
the `facts` operator prevents "special-case" facts -- facts for specific nodes
that aren't usually defined -- from causing rampant error-raising. The result
helps defend against human error while providing an easily-accessible override.
Refuse to bind nodes if any tag raises an error

To prevent accidental binding of nodes to policies due to typos, no node is
permitted to bind to a policy if a tag raises an error during evaluation.
To aid in troubleshooting, the node appends an error message to its log with
details of the failure.
Add num, gte, gt, lte, lt matcher operators

This adds standard numeric greater-than, less-than, and their respective
-or-equal operators to the tag matchers. Since these currently support only
numeric values, a `num` operator is also provided, which attempts to convert
its argument into a numeric equivalent. While the gt, lt, etc. operators are
useful of themselves, `num` is provided as a continuation of the 'explicit
rather than implicit' pattern.

`num` supports binary, octal, decimal, and hexadecimal integers, and floating-
point numbers in decimal or scientific notation. All values can be passed as
strings or as literal numeric values. Any other values will cause a
Razor::Matcher::RuleEvaluationError to be raised.
Whitespace changes

Just formatting to make stuff look nicer
* lib/razor/messaging/sequel.rb: add missing require's of razor environment
Add a 'command' helper to make command behavior more uniform

Also generate the 'collections' entries from an explicit list
Rationalize the use of spec/rel URL's
Object reference is an abbreviation of full details; id is always a URL
Replace '_' in command names with '-'

Eventually, our command line client will offer commands like 'create-tag',
and that looks better than 'create_tag'
Tests: when creating atgs, use the simpler :rule instead of :matcher
Razor::Data::Tag.matcher: make mandatory

Tags with a NULL rule make very little sense
Tags through the API only have rules

Hide the whole matcher business from the API; it's an implementation detail
Try a little harder to produce valid JSON errors from API
* Rakefile (spec:cli): run only CLI tests
CLI: add support for commands
* config.yaml.sample: document installer_path
CLI: simplify error handling and reporting

We don't need our own RequestError; RestClient's exceptions already have
all the needed information, albeit in very hidden places.

Print as much information as we have to the user when we get an error from
RestClient
create-image command: document and rename image_url param to image-url
fixup! 2b02047b