reference file cache

cc @rjzamora

Following the success of caching pieces of files for parquet reading, I wonder if we can think of a use case combining this with the kerchunk method. I am thinking, that each piece of a file like might be fetched from different sources - proactively (as with parquet) or on demand.

I am thinking that this idea might allow us to construct arrow-like datasets from any data format (including parquet) where the data itself is some compressed buffer that translates directly to an arrow (or numpy) buffer on load. Exactly how to do this is another matter, but I thought people might have some insight on whether this kind of thing might even be useful, if it were done.

Start by reviewing the existing file-piece caching approach for parquet reading and the kerchunk method referenced in the issue. No files, tests, or entry points are identified in the payload; progress would require establishing whether the proposed combination is useful and defining how it could support data formats that load compressed buffers into Arrow or NumPy buffers.