Adds KeyValueAccess.createReadData which enables implementations to return a backend-specific lazy- and ReadData, that can enable partial reading if the backend allows. The abstract class KeyValueAccessLazyReadData handles the main logic.

Two implemenations are provided: FileLazyReadData and HttpLazyReadData, both of which can only be made through their respective KeyValueAccess.createReadData methods.

Main questions have to do with the behavior of slice methods relating to boundary conditions. The current behavior is ensured by ReadDataTests:

• calling slice with a negative offset immediately fails
• calling slice with a too-large length succeeds, but will fail when attempting to materialize / read
  • failing immediately would be possible but would require a backend check for data length, which we'd like to avoid

Note: This will need revising assuming we merge #155

Overall looks good to me. Something I'm thinking of though

• I still think we should try and remove split and use slice for now, unless we find a use for it, in which we can add it.
• I'm not sure we need an explicit lazySlice that is separate from slice. I'd like to make the assumption that all ReadData are "lazy" and if I ever need it materialized, I would just call material on it. I don't think that's always going to be true, but I think that's probably how I would treat an arbitrary ReadData

I'm not sure we need an explicit lazySlice that is separate from slice

just to clarify - lazySlice is a private method in KeyValueAccessLazyReadData that is used by the public slice api method, so this doesn't really "add" a lazyslice method