[Feat] i.sentinel.import: handle processing baselines

[ninsbl]

Name of the addon
Processing baselines of Sentinel-2 are regularly updated. Some changes may pose significant changes in the data (as e.g. baseline 4.00):
https://sentinels.copernicus.eu/web/sentinel/technical-guides/sentinel-2-msi/processing-baseline

i.sentinel.import should issue a warning when data with new processing baselines are encountered that the module is not known to handle.
So, a list of "supported Baselines" should be added and checked against. That increases the need for maintenance a bit, but avoids surprises for users...

As for the BOA offsett introduced in baseline 4.00, I would suggest that i.sentinel.import accounts for that (if requested by the user) and rescales accordingly...

Expected behavior
Users are made aware of changes in processing baselines, and the module is updated/adjusted if needed.

[ninsbl]

Not sure if this actually should be flagged as a bug, as i.sentinel.preproc and i.sentinel.mask will likely fail with un-adjusted baseline 4.00 data...

[ecodiv]

@ninsbl Does i.sentinel.import do anything with the rescale (QUANTIFICATION_VALUE) factor? If I import Sentinel-2 data, the imported bands have the unscaled (original) value. And I can't find where rescaling should take place in the i.sentinel.import code.

The page you link to gives the following information for processing version 5.0: " The Processing Baseline identifier 05.00 tags every Sentinel-2 Collection-1 product issued from the reprocessing activity. As part of the Sentinel-2 reprocessing campaign, the improvements introduced in recent processing baselines 04.00 deployed on 25 January 2022 is generalised to the historical archive". That suggests that older images now also are based on the new processing baselines? Indeed, if I download an image from e.g., 2021, the MTD-MSIL2A.xml file does provide the BOA_QUANTIFICATION_VALUE unit=10000 and BOA_ADD_OFFSET band_id=-1000 (for all bands).

Do you know how this affects the use of i.sentinel.mask? For the latter, would it just be a matter of adding the option to provide an offset value, besides the existing option to provide the rescale factor? Or should the rules used in i.sentinel.mask be adjusted to account for possible negative values?