Make sure that nodes with nil facts/metadata/state do not case an internal error

When a node had nil facts/metadata/state, the matcher could fail by trying
to call nil.[] in value_lookup; this change makes sure that doesn't happen,
and that evaluating ("fact" "foo") against a node with nil facts actually
raises a RuleEvaluationError

This change also adds some light testing for Tag#match? as that is the main
user of matchers

Issue: https://tickets.puppetlabs.com/browse/RAZOR-254 (partial fix)
* spec/data/tag_spec.rb: check that Tag.match raises when rule eval fails

Other things, especially Node.checkin depend on that behavior; out of
overabundant caution, add a test for that. It is also checked indirectly in
the tests for Node.checkin
Tag#eval_nodes should catch rule evaluation errors and log them to the node

When matching against a node fails for some reason, we want eval_nodes to
continue to evaluate against other nodes; to make it possible for users to
spot problems, we log the evaluation failure into the affected node's log.

Before this change, eval_nodes had raised the RuleEvaluationError causing
the background processing for update-tag-rule to fail in its entirety with
no indication to the user what exactly was wrong, other than a cryptic
entry in the server log

Issue: https://tickets.puppetlabs.com/browse/RAZOR-254 (final change)
Significantly change how we identify nodes to reduce the risk of data loss

We used to assume that calls to /svc/boot would completely identify nodes;
this had two important shortcomings:

  * it was not possible for users to identify nodes based on facts (e.g.,
    HDD UUID's) so that even changing the mainboard of a machine will not
    lead to assuming a node is new; changing a mainboard is fairly common
    in large operations, and it is generally hard to coordinate that with
    manually changing the Razor database

  * if the HW info that iPXE sent us did not give us the complete picture
    of the hardware, e.g. by using undionly.kpxe, which will only send us
    the MAC address on which the machine did its DHCP, we could
    accidentally identify the same physical node as two separate nodes in
    the database (if DHCP happened sometimes on one NIC and sometimes on
    another NIC) with the attendant risk of data loss

With this change, Razor makes another attempt at identifying the hardware
during requests to /svc/checkin at which point we have the full facts about
the node. If a previous request to /svc/boot misidentified the node and
created a new entry in the database, /svc/checkin will now detect that and
clean up the database by merging the newly created node (which will not
have facts yet as these are not set by /svc/boot) into the existing node.

Most of the work of deduplication is done in Node.register.

Users can now guide deduplication by having Node.register match on certain
facts, controlled by the facts.match_on configuration setting, which by
default is empty. Users must ensure that the facts they use to identify
nodes are truly distinct across their machines, otherwise physically
distinct nodes might get coalesced in the database.