Support a Secondary Node Identification Strategy:

Currently, an attempt to identify a node is made during boot using the
mac address only (potentially the UUID as well).  There is a risk,
particularly with highly integrated systems such as blades where the
NICs are onboard that, should the mainboard need to be replaced Razor
will not be able to identify the node and data loss is a possibilty
depending on the policy setup.  In this scenario, the mac and UUID would
have to be manually updated on the node in the Razor database before the
node is booted on the network and given that in large operations, tasks
such as mainboard replacement is usually carried out be a vendor tech,
lining this manual process up would be difficult.

This patch allows razor to have a second go at identifying a node using
the full compliment of facts available once the MK has loaded.  The
facts to be used are configured in the config file as regex strings. The
facts used will have to be guarenteed to have unique values across all
nodes and shouldnt change often on the node.  I have a fact that
generates a fact per partition yielding the UUID of that partition. In
testing, I configured a regex that would match any
'blockdevice_<dev>_uuid' fact.  In theory, unless the mainboard with the
dhcp_nic was replaced and then an offline modification of the filesytems
was made before Razor had seen the new MACs, Razor will identify the
machine using the partition UUIDs and update the hw_info.

The following behavior changes have been implemented:
  - /svc/boot will not result in a new node being created in the DB for
    an unknown node, it will simply result in the MK being loaded.
  - When loading the MK, the node id, in the case of a known node
    without a policy/recipe, will be added to the kernel params as a
    separate field and not attached to the register URL.
  - The '/:id' on /svc/checkin is now optional.  If it is missing, the
    secondary_lookup class method on Razor::Data::Node will be fired
    with the list of facts supplied.  The facts identified as matching
    the regexes in the config will be matched against the facts of each node
    in the DB.  If all facts match the facts of a node in the DB, the node
    is considered to be that node.  The node id is returned with the action
    in the return to the client and the hw_info and dhcp_mac is updated
    so that the standard lookup on subsequent boots will succeed.  If the
    node is not identified, a new node is created and the id of the new node
    is returned to the client.