Refactor file format backend openers about kerchunk HOT 1 OPEN

I would first point out that there is a little bit of consistency injected via classes that call functions, e.g., kerchunk.grib2.GribToZarr is a class designed to feel similar to kerchunk.hdf.SingleHdf5ToZarr.

A general file dispatch system seems reasonable, possibly something that belongs in Intake 2 (which already tries to guess file types by URL pattern matching or reading magic bytes). We probably don't want to replicate work in pangeo-forge, though?

Should there be some arguments that are valid for every backend (e.g. inline_threshold), and others that are specific to particular backends?

There are definitely operations that will be the same for all backends, like inlining.

On virtual zarrs, this sounds something between nsidc/earthaccess#278 and a special xarray engine="scan-kerchunk". The trouble is, as with everything kerchunk, is that there are many options (such as what to do with gribs...) and it becomes hard to specify them all in a reasonable way. Not all of kerchunk will be xarray friendly (and maybe not even zarr).

• do we need to be strict about the steps taken to make reference sets, or will this always be ad-hoc for the heterogeneity out there? This is what pangeo-forge recipes do, or an intake pipeline could, but there are tradeoffs.

from kerchunk.