>Why are we going back to granularity?

Determining the src and dst column family has become a more difficult
computation.  Rather than make this a surface area for bugs during locator
fetching and rollup dispatching, I thought it would be easier to catch and
deal with as part of the rollup calculation inside of `RollupRunnable`.

I think it is a cleaner interface: the source and destination column family
is a function of granularity and metric type.

On a tangent, I'm still of the opinion that introducing Astyanax
ColumnFamily objects outside of the Reader/Writer objects is a coupling
that will make it difficult to do fun things with the code in the future
(like mock Reader/Writer objects and get rid of the abhorred integration
tests or use a different data store all together).

> I think we should figure out a way to map metric names to source and dest
column family.

That's basically what is happening.  During ingestion we determine the
metric type (counter, gauge, timer, etc.) then store it as meta data.  That
metadata gets consulted during rollup now.