Refactor file format backend openers

Problem

The API for Kerchunk's file format backend openers doesn't follow a consistent pattern.

Suggestion

Change the openers to each be a function returning a VirtualZarrStore (see #375), with standardized keyword arguments.

Advantages

• Neater
• Can any common standardize keyword arguments
• Can do validation within file opening or immediately afterwards
• Would make it more obvious how to add a new opener for a new file type
• Could also allowing implementing a general file opener (like is done in pangeo-forge)

Implementation ideas

• Perhaps each opener should inherit from a single abstract method?
• Should there be some arguments that are valid for every backend (e.g. inline_threshold), and others that are specific to particular backends?

Questions

How to handle GRIB files? Combine before returning? Return as a hierarchy of multiple groups within a single store (like when opening with datatree)? Or return as list of VirtualZarrStores?

Start with the file-format backend API in the linked reference documentation, then read #375 and kerchunk/grib2.py to compare the proposed VirtualZarrStore return shape and GRIB handling. Done means the opener interface and keyword-argument rules are decided and consistently applied, including an agreed approach for GRIB files.