[Feature] Support sensor-specific file format

[fmigneault]

GDAL handles by itself BEAM-DIMAP format. Processes could support this format with a twist (ie: zipped variant) if they desire so, but still up to the process to manipulate the data.

A typical BEAM-DIMAP is composed of a <product-id>.dim file and a <product-id>.data directory with many other files under it.

To differentiate from any other zip, we could have application/dim+zip since there isn't any explicit mime-type for it. This would help a process figure out if it should unzip the file first and then change .zip t .dim to find everything where expected.

With BEAM-DIMAP-specific ZIP format, we still have a problem regarding different sensors (Sentinel, RADARSAT, etc.) that employ the same "file format" although very different underlying structure. We need a more accurate method to indicate how to filter inputs/outputs for those specific use cases (eg: Process working only for a given type of sensor).

Relates to opengeospatial/ogcapi-processes#38

[smrgeoinfo]

what about using parameters on the MIME type, e.g. application/zip; type=beam-dimap, application/zip; type=beam-dimap-sentinel, etc.
The application/zip registration doesn't specify any parameters; Would adding a parameter would break anything?

[fmigneault]

@smrgeoinfo
I don't think that would break anything.
Obviously, it would work only within Weaver since it is not standard.