Pull in complete UEFI network boot support. [4/7]

This pull requests series adds several things needed to make network
booting via UEFI operate at the same level as out current PXE support:

 * Add support for managing the boot sequence when running in UEFI
   mode.

   Crowbar now knows how to manipulate the boot sequence using
   efibootmgr when running in UEFI mode.  Boot sequence manipulation
   is the responsibility of the crowbar-hacks recipe in the deployer
   barclamp, and it currently only knows how to switch between
   nics-first and nics-last mode.  The recipe records its state in
   node[:crowbar_wall][:uefi][:boot], and that state includes the MAC
   address of the last NIC we booted from when booting in UEFI mode.
   
 * Use per-node OS installation config files instead of per-OS ones.

   Support for installing Redhat/CentOS via a UEFI netbooted
   installation is not complete, so I needed to make sure that the MAC
   address information for the install was passed in a way that was
   compatible with the way pxelinux does it.  While I was at it, I
   went ahead and modified the rest of the operating systems to also
   use per-node OS installation config files to keep from having to
   maintain multiple codepaths through the OS installation code.

 * Have the provisioner run chef-client calls on the nodes whenever
   they transition away from the execute state.

   None of the UEFI compatible bootloaders seem to have pxelinux's
   capability to give up tryin to netboot and fall back to booting off
   the hard drive.  However, since we have efibootmgr, we can emulate
   that functionality by telling it to set the boot order back to
   nics-first.  To do that, I modified the provisioner to detect when
   it is transitioning a node away from execute and have it run a
   chef-client call on the node that is transitioning as part of the
   transition process.

 * Clean up how we handle node resets and deletes.

   Making the provisioner call chef-client on nodes as part of its
   transition function exposed a few bugs in how we handle node
   resetting and deleting.  To address those, I made the following
   changes:
   
   * The network barclamp detects when it has been asked to deallocate
     the last IP address on the admin network.  When that happens, it
     will run dhclient on each of the nics one at a time until it gets
     an IP address.  This should usually result in it getting the same
     IP address it had statically allocated, because the sequencing of
     chef-client runs in a state transition is such that the
     chef-client run on the admin node that winds up rewriting the
     dhcp config files happens after the chef-client run on the node
     itself.  Since the node gets the same IP address it had, the
     connectivity test in the recipe passes and the final chef-client
     run on the node can finish.

   * The nagios and ganglia barclamps have been modified to shut down
     and deconfigure their services on a node that is being reset or
     deleted.

   * Responsibility for doing the final delete of a node's Chef node
     object and role object has been pushed from the update_nodes recipe
     in the deployer to the crowbar_service model in the Crowbar
     barclamp.  This ensures that the objects are present at all
     places they are needed during the transition.

   * The provisioner-server role has been reordered a bit so that
     update_nodes happens after setup_base_images.  This ensures that
     update_nodes has all the information it needs from
     setup_base_images.

   * blocking_chef_client has been rewritten to make
     looper_chef_client redundant.  Looper_chef_client has been
     removed, and single_chef_client now just calls
     blocking_chef_client directly.  With the new
     blocking_chef_client, there can be at most 1 instance of
     blocking_chef_client actually running a chef-client process, 1
     instance of a blocking_chef_client waiting to run a chef-client
     process, and any number of blocking_chef_client instances waiting
     on the one that is waiting to run, and which will exit without
     doing anything once they are no longer waiting.