Use new synchronization helpers to avoid races when deploying with HA

There are a number of possible races when deploying neutron for the
first time:

 - when creating of the database / database user
 - when registering the endpoint and creating users in keystone
Manage neutron-server with pacemaker

We create the primitives/clone resources (protected with
crowbar_pacemaker_sync_mark) and we use the
Chef::Provider::CrowbarPacemakerService service provider.
Merge pull request #66 from vuntz/sync-marks

Use new synchronization helpers + manage services with pacemaker
Rename [:ha][:enabled] attribute to [:ha][:server][:enabled]

This will allow us to introduce :ha][:l3][:enabled] later to differentiate
between the HA setups of neutron-server and l3-agent.
Skeleton code for l3-agent ha

This introduces the HA enablement pieces for the l3-agent. Currently this l3_ha
recipe is still a dummy and does nothing useful.
Implement l3_ha recipe

Create pacemaker primitive, group and clone for the various neutron agents.
Setup the neutron-ha-tool to perform automatic migrations of offline
routers.
l3_ha: Don't start l3-agent when using "vmware" networking
Include linux-bridge/ovs-agent into the l3 HA group
Add an order constraint for neutron-ha-tool

This should make sure that the neutron-agents clone is started before the
neutron-ha-tool primitive. Otherwise neutron-ha-tool might cause unneeded
router migrations.
Use pacemaker service provider when HA is enabled
Derive the resource agent name attributes from the service names
Only install ha-tool package on platforms that have it
Use synchronization helpers in l3_ha to avoid races when deploying with HA