pool.sks-keyservers.net GPG key server is unreliable

The `pool.sks-keyservers.net` machines occasionally time-out trying to fetch
the GPG key, which leads to an acceptance test failure - because we can't get
the key required to install Puppet, which means we can't install Razor.

We should make sure we at least try more than once to fetch the key, and
ideally use a second source so that we increase the chance of successfully
finding the public key material.

This shouldn't change the overall robustness of the system because all the
various key servers exchange keying data with each other routinely, and we are
not looking for keys that rapidly change.

This implements that, trying with `pgp.mit.edu` and then `keyserver.pgp.com`
if we fail on fetching the key from sks; that should be fairly robust.

Closes #375.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Added Razor init scripts for Debian and RedHat

This adds wrapper init scripts that smooth the path between the `daemons`
based Ruby script for starting the Razor service and the system.

That consists of providing the correct sequencing and packaging hooks to end
up invoking that Ruby script to perform the actual action.

This ensures that LSB tools, chkconfig, and related system integrations will
behave as expected when the packages are installed.

This closes #320 for now.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #376 from daniel-pittman/feature/master/375-increase-gpg-key-server-robustness

pool.sks-keyservers.net GPG key server is unreliable
Merge pull request #320 from daniel-pittman/feature/master/320-implement-real-init-dot-d-script-for-razor

Implement a real init.d style script for Razor
Merge pull request #322 from daniel-pittman/feature/master/322-refuse-to-install-over-git-deployments

Ensure that the Razor packages will not install over an existing git-based deployment.
Handle platforms with "purged" packages in git install test

When we validate that packages refuse to install over the top of an existing
git-based deployment, we end up with a package that isn't installed.

Unfortunately, that is represented by two distinct states in Puppet, `absent`
and `purged`, with only a subset of platforms supporting the later state, and
even then, only sometimes reporting it.

This means that the test was broken in the real world: it reported `absent` on
my test bench, but put into production it reported `purged`, and we
incorrectly decided that the package was installed when it actually wasn't.

This makes the obvious update to the check, so that we handle both cases, and
should fix the acceptance test failure after #322 merged.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>