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.