Add Graphite module & role

This patch adds a module for Graphite, a platform for aggregating, storing and
plotting metrics in real time. It is designed to obsolete (and improve upon)
the Graphite setup on professor.pmtpa.

Broadly speaking, the setup contains two halves: Carbon, which listens for
metrics, writes them to disk, and computes summary statistics, and Graphite
webapp, which provides a web-based interface for navigating and graphing metric
data.

The Carbon setup matches the setup described in
<http://bitprophet.org/blog/2013/03/07/graphite/> (cf. "Single node, multiple
carbon-caches"): All metric data goes through a single carbon-relay instance,
which forwards each data point to one of four carbon-cache instances, using a
consistent hash ring to distribute the load. Distributing the load across
discrete processes is necessary because carbon-cache is CPU-bound and the
Python GIL prevents it from using multiple processor cores efficiently.

Data retention is configured as follows: data is retained with one-minute
resolution for one year and at a ten-minute resolution for ten years. It is
possible to dream up very elaborate retention strategies, but the benefits they
offer are flimsy, based on shakey predictions of future usage patterns, whereas
the benefit provided by a super-simple and memorable retention scheme is real
and immediate.

The web app is configured to use uWSGI as an application container with Nginx
in front. Although uWSGI itself can be configured in absurdly complicated ways,
running a Django app behind Nginx is the classic use-case of uWSGI, and setting
it up properly is actually more straightforward than the alternatives
(gunicorn + nginx / apache + mod_wsgi).

Carbon is managed using a set of custom-written Upstart scripts. The Carbon
init script is both crufty and limited to a single instance, and I believe that
the Upstart setup included in this patch is superior. An apachectl-like
management script, carbonctl, is included; it provides quick access to
common Carbon process management tasks and (when invoked with 'check') doubles
as a Nagios / Icinga plug-in.

My two points of self-critique are the lack of a decom manifest (or $ensure =>
absent support) and the complexity of web.pp, which could probably be broken up
into multiple sub-classes. Oh well; maybe later.

Change-Id: If563923aa55aef77111637aacbb6a93950d9066e