WIP: Deriving type-safe interfaces for rollup generation.

NOTE: this PR is based on @lakshmi-kannan 's PR to add histograms.

Here are the goals:

1. Avoid a great deal of `instanceof` checks.
1. Avoid the branches we currently have that treat rolling up of full-res data specially (there should only be one method in the final interface).
1. A very simple implementation for RollupRunnable
1. Avoid casts in methods that implement work.

This currently gets us part of the way there by:

1. using `Rollup` as the type in all methods that do work.
1. removes all casts to children of `Rollup`.
1. provides a type (albeit a very generic one) in all uses of `Points`.
1. promotes `Rollup.Type` to a class (was an enum) and charges it with calling the right implementation methods.  This will eventually allow us to specify how a rollup is computed when the `RollupContext` is created.
1. turns `Rollup` into almost an interface.
1. `SimpleNumber` implements `Rollup`. (it is a rollup of one datapoint).

The last parts remaining to be done are:

1. `Rollup.Type` becomes a single method interface with four implementations (simple->basic, basic->basic, simple->histogram, histogram->histogram).
1. `Rollup.Type` is specified during construction of the `RollupContext` by examining the src and dst column families.
1.  Figure out how to address the problem that `Rollup.Type` will not be known when the `RollupContext` object is created.  I have some ideas here, but nothing is firm in my mind.  There are basically two questions whose answers will derive how to derive a `Rollup.Type` which will determine how a rollup is computed:
  1.  which are the src and dst column families (remember, these will be different in the case of histograms)?
  1.  when deserializing the the src column, what is its type?

These things all need to be resolved before we can properly implement histogram support or support for the specialized statsd/graphite metric types.