Clean and export the units registry

[aulemahal]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes #xyz
• Tests for the changes have been added (for bug fixes / features)
  • (If applicable) Documentation has been added / updated (for bug fixes / features)
• CHANGELOG.rst has been updated (with summary of main changes)
  • Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

• Remove support for non-CF aliases : "cms" (m3 s-1), "mmday" (mm d-1) and "pct" (%). These are not supported by udunits2 and thus I don't see why we should support them ? @huard, @RondeauG what do you think ? I'm not strongly opinionated on this.

• Set the unit registry as pint's "application registry" to make it usable by non-xclim aware applications. To be obtained with ureg = pint.get_application_registry().

• Units of quantities printed in indicator attributes are now formatted using the CF syntax (ex: "mm d-1" instead of "mm/d"). Not sure how I missed that earlier...

• Clean up in the code of the registry declaration and addition of comments to explain what is happening.

• A small change in dataflags that was actually unneeded at the end, but it felt cleaner to me, so I kept it.

Does this PR introduce a breaking change?

Some units are not supported anymore (cms, pct and mmday).
Some attributes will be different as the units are printed differently (for fractions mostly).

Other information:

The registry export allows an application/module that is units-agnostic in itself to be used with xclim. For those applications / usages, the import order might be significant though : xclim has to be the last set_application_registry done. Specifically in the climate case, as xclim.core.units imports cf_xarray.units (which also sets the app registry), a subsequent import cf_xarray.units is not problematic as python will not actually execute it.

@coxipi Incoming PR to xsdba to use exactly that.

[Zeitsperre]

LGTM, but some clarifications would be nice to have!

[huard]

The non-standard units are stuff that we've seen in the wild. I suspect that removing them here will force us to make explicit unit changes in RavenPy and maybe xhydro.

I'm not sure I see why we'd remove them if it doesn't cause us pain. I think our stance is "we'll make sure CF-compliant files work", not "non CF-compliant files will fail".

[coveralls]

coverage: 89.946% (+0.01%) from 89.934%
when pulling 7def13d on clean-units
into d491487 on main.

[aulemahal]

I can put them back.
But my long-term goal is to move units-handling elsewhere, most probably cf-xarray. And I doubt that this is a good place for those aliases (they already copied the registry from us and did not copy those).

[huard]

I can put them back. But my long-term goal is to move units-handling elsewhere, most probably cf-xarray. And I doubt that this is a good place for those aliases (they already copied the registry from us and did not copy those).

Ahh, I see now. @Zeitsperre expect some breakage in notebooks and tests from ravenpy and pavics-sdi.

[Zeitsperre]

I'm prepared for that if it means that things are improving overall. PAVICS pins xclim, so no current images should be impacted.

[RondeauG]

Sorry, I skipped this conversation.

Remove support for non-CF aliases : "cms" (m3 s-1), "mmday" (mm d-1) and "pct" (%). These are not supported by udunits2 and thus I don't see why we should support them ? @huard, @RondeauG what do you think ? I'm not strongly opinionated on this.

These are not anywhere in xHydro, so personally, I don't mind removing support for them.