Move `rule` from Tag to nested matcher object

Moving the `rule` field from Razor::Data::Tag to a nested Razor::Matcher object
will allow matchers to be validated independent of their host tags.
Add static rule validation to Razor::Matcher

This adds a #valid? method to matcher instances which ensures that their rule
matches the expected [operator, arg0, ..., argN] format. It ensures that each
operator is recognized, that the types of arg0-N can be handled by the operator
(after substitution), and that the top-level expression returns a boolean.

Though Ruby will happily evaluate `1 or 'fish'` and `'seven' and 4`, these make
no sense in terms of the boolean values that matchers are supposed to emit.
By defining explicitly the types of values returned by each operator, and what
values the operator is capable of processing, such travesties of logic can be
avoided. `and` and `or` are labeled as accepting and emitting only boolean
values, and so `["and", 1, "fish"]` and `["or", 'seven', 4] are correctly
recognized as invalid rules.

One side effect is that it is not possible to directly treat the output of the
"fact" operator as a boolean even if it is known to be so. Take, for example,
the rule `["fact", "is_virtual"]`. The logically equivalent and valid
expression would be `["eq", ["fact", "is_virtual"], true]`.
This is, admittedly, a little more verbose, but necessary for this sort of
static type evaluation.
Add error messages with Razor::Matcher#validate

This is mostly so people don't start pulling their hair out upon finding that
something like '["=" ["fatc" "f1"] 5]' is invalid. Instead of simply finding
that validation has failed, one can now call Matcher#errors to get a list of
error messages; in this case, the message would be something like

    "uses unrecognized operator 'fatc';
    recognized operators are [...]"

The messages are meant to follow the Sequel::Model::Validations format for
the field :matcher, though it makes some of the wording awkward.
No functional change - whitespace cleanup
* Gemfile.lock: update various gems to latest version
Razor::View#view_object_url: use object name in URL, compute collection name
Images: return correct reference from create_new_image; list/show images
Installers: return correct reference from create_installer; show installer query
Razor::Data::Tag::find_or_create_with_rule: idempotent find/create

This method will be used by create_tag and create_policy
create_tag command and very light testing
Rename Policy.sort_order to line_number and constrain it more

Calling it line_number will hopefully make it more intuitive that policies
are evaluated in ascending order (and it's what the old Razor called it,
too)

Also, insist that line_number is non-NULL and unique
Validate that named installer exists when saving policy

This is much weaker than a fk constraint, but better than no check at all
Revamp how hostname etc. in nodes gets set

The hostname_pattern for a policy is now assumed to produce fully-qualified
names (including domain)

The node now stores its own hostname, which is populated at the time when
the node is first bound to a policy; calling 'hostname' on a node that is
not bound is now legal, and will return nil.

The data model ensures that bound nodes always have a non-null hostname and
root_assword
Change interpolation of id into hostnames

The policy's hostname_pattern can now contain a '${id}' (rather than '%n')
to put the node's id into the hostname. This change is mostly there to
leave us some room to make other data available for use in
hostname_patterns - the '${expr}' syntax will just be more amenable to that
than the '%special' would be.
Command to create a new policy