RasterSource Transformation ADT

[echeipesh]

Ref: #138

This actually leads me to another point which is RasterSource currently mixes (at least) two concerns that may deserve to be separated:

• How to read (sub-)rasters (efficiently)
• How to do that while efficiently transforming the data into the desired form without large data copies

(Do you agree? Have I missed any?)

The first is obvious and core to the abstraction. The second is technically a performance optimization, but a required one. My gut says this responsibility could be separately abstracted, using something akin to an AST (maybe even a linear one), providing easier testing, reusability, and less implementation bleeding.
@metasim

There was also a suggestion from @jbouffard to add some kind of inspect-able way to query that RasterSource transformations as part of the CellType conversion PR.

I think this is worth a discussion to determine if the benefits are worth the refactor.

Outcome of this issue is either a work task issue to implement something along the lines of suggestion or explicit decision not to do it.