Support for creating a store-service for Storm platform

To be able to do leftJoin on a store we need the same object to serve as a store and a service. This is already supported in the Scalding Platform (https://github.com/twitter/summingbird/blob/1b630690a8efe554ab3fabc9b60965c2c95e2e83/summingbird-scalding/src/main/scala/com/twitter/summingbird/scalding/Service.scala#L46). This adds a trait to the Storm Platform that is of both P#Store and P#Service types. This can be used in jobs that use leftJoin against store. Users in their jobs can call:

```
Storm.storeService(mergeableStore, serviceStore)(batcher)
```
where the mergeableStore is the store for aggregation (delta store) and serviceStore is the store that we use as a service (can be delta store or the total store). For read-modify-write behavior the serviceStore should include the delta store, i.e. serviceStore can be a client store that wraps the delta mergeableStore or a client store that wraps the delta mergeableStore and the offline store (i.e. the total store). 
I don't think we want the latest key, we want the latest that is before the timestamp of tuple coming in. Consider the fact that the queues get delayed, and the fact that we have batch boundaries. You don't want some part of the topology (some queue for instance that is low traffic), to get ahead update a service so the the backed up queue is looking into the future.

It is not a huge source of errors, but I think it is more consistent to give a BatchID in the key when doing a service read, but some stores might ignore that (using [composeKeyMapping](https://github.com/twitter/storehaus/blob/develop/storehaus-core/src/main/scala/com/twitter/storehaus/EnrichedReadableStore.scala#L47)) to discard the BatchID and just look up the key. But if we bake into the API the fact that the BatchID is not available at lookup time, there is no way for a user to make a more precise store.



What do you think?