Allow coverage providers to specify the output formats they can serve

[barbuz]

Is your feature request related to a problem? Please describe.
The output formats that providers can serve are fixed in the describe_collections function of the API class.
For coverages, these formats are are coverageJSON and the native format of the collection:

pygeoapi/pygeoapi/api/__init__.py

Lines 1110 to 1124 in 474cb60

	collection['links'].append({
	'type': 'application/prs.coverage+json',
	'rel': f'{OGC_RELTYPES_BASE}/coverage',
	'title': l10n.translate('Coverage data', request.locale),
	'href': f'{self.get_collections_url()}/{k}/coverage?f={F_JSON}' # noqa
	})
	if collection_data_format is not None:
	title_ = l10n.translate('Coverage data as', request.locale) # noqa
	title_ = f"{title_} {collection_data_format['name']}"
	collection['links'].append({
	'type': collection_data_format['mimetype'],
	'rel': f'{OGC_RELTYPES_BASE}/coverage',
	'title': title_,
	'href': f"{self.get_collections_url()}/{k}/coverage?f={collection_data_format['name']}" # noqa
	})

This cannot be changed on a per-provider base, so it is not possible for providers to support additional output formats even if this would be easy to do.

Describe the solution you'd like
It should be possible for each provider to specify a list of formats they can provide output in, this could be set as an attribute of the BaseProvider class (an empty list by default) that can be overridden by any Provider implementation with a list containing the actual additional formats supported (with coverageJSON and the native collection format always being implicitly supported).
The values in this list can be used when generating the list of links for a collection, and must be accepted by the provider class as values of the format parameter of the query function.

Describe alternatives you've considered
The list of additional formats supported could also be part of the configuration for a specific dataset, but I think it makes more sense to make it a fixed value for a provider as it depends on the capabilities of the code itself.
A similar change could be implemented for features providers, but the output format for them is managed outside of the provider (they just return dictionaries), so for them it makes more sense to manage output formats at the API level.

Additional context
The idea for this was born while working on the xarray provider, and realising that it can manage either NetCDF or Zarr data, but can answer queries only in the same format as the input data (or JSON), even though it is loading the data in memory before writing the output, so it would make no difference to provide the output in one format or the other regardless of the native format of the data. In fact, the code for the xarray provider as it currently is would be able to convert between NetCDF and Zarr, but it is prevented to do so by the API, which does not allow f=zarr for a query on a NetCDF dataset and vice versa.

I have proposed a change to fix this issue as part of a PR addressing the xarray provider, but was rightfully suggested to separate this into its own discussion.