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.
Collapsing secondary_lookup into lookup.

This commit consolodates the 2 lookup methods on Razor::Data::Node.  It
also ensures that if no facts are configured for 'match_nodes_on_facts'
in the configuration file then the traditional workflow is unchanged. Ie

If config contains 'match_nodes_on_facts':
  - /svc/boot call will attempt to match node
  - If no match is found, booth the MK. DO NOT CREATE NEW NODE
  - MK does /svc/checkin (no ID)
  - Razor attempts to match the node based on facts
  - If no match, New node is created and then the checkin proceeds as
    that node. The id is included in the response for the client to use
    in susequent checkins
  - If a match is found, the checkin continues as that node, the hw_info
    for the node is updated and the id is sent back to the client to use
    on subsequent checkins.

If config does not contain 'match_nodes_on_facts'
  - /svc/boot call will attempt to match the node
  - If no match is found, Create a new node and send the id in the
    kernel boot params and boot the MK
  - If a match is found, do what ever the task assigned to the node
    dictates.
  - This is the tradidtional behavior.

Note that this PR depends on PR
https://github.com/puppetlabs/razor-el-mk/pull/18

Also note as in other commit, the microkerne_kernel_args sends the
register url and ID as separate params now.