hRaven Reducer Estimator

Adds new "scalding-hraven" module with an estimator that looks up job history in hRaven to determine the actual amount of bytes reaching reducers. The `HRavenHistory` trait can be added to a `ReducerEstimator` to add functionality for looking up job history, and the `RatioBasedReducerEstimator` does this, scaling the estimate provided by `InputSizeReducerEstimator` based on the past ratio between mapper/reducer input sizes.

This PR also includes a couple other minor changes:
- Using a case class as argument to `estimateReducers` to hold the common reducer estimator info (`flow`,`step`,`predecessorSteps`)
- Add optional `fallbackEstimator` which lets estimators be chained

So far I don't have a story for unit testing hRaven. Any ideas are welcome.
I guess I was imagining that there would usually a pretty intuitive choice for each estimator which one should be the thing to fall back to. But I guess we can't necessarily assume estimator succession will always be tree-like.

Estimator is specified as a class name in a config parameter -- people shouldn't have to write/compile their own case classes to compose estimators. Perhaps the right approach is to allow specifying a list of estimators, then we can just monoid them all together as you said.