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.