RasterSource.nativeTileLayout: Option[TileLayout] property

[echeipesh]

Some files are large but user may not really care how to read them, they simply need to be chunked.
Some instances of RasterSource may have a tilting scheme in the underlying data format.

GeoTiffRasterSource the tile scheme is the segment layout of the GeoTiff segments.
GDAL similarly exposes "native" segment layout (reference needed)
GeoTrellisRasterSource has the LayoutDefinition in which the underlying GeoTrellis layer is tiled

This should be optional property, as it's mostly an optimization. When chunking does not matter, using underlying chunking will reduce merging and lookup costs, reducing both memory and IO requirements for a read.

Also we should consider how this information will be used to actually read the chunks to make sure that the Option[TileLayout] is the most useful signature for this method. Other option might be LayoutDefinition.

[echeipesh]

This is open question. @metasim had API similar to this but seems to have backed out of the idea. I will say that I have not yet keenly felt its absence in current API.

[metasim]

@echeipesh I reinstated something on top of VLM-RasterSource, but isn't truly "native" (you set the tile size). After the experiment with the prioir "native layout" approach, I'm not sure how much exactly aligning with the internal gridding helps, and when you add the need for BufferedTiles, the work seems too much of a hassle. I think providing a means of getting the RasterSource as a gridded set of tiles of arbitrarily regular size (as in the link above) is sufficient.