As a user, I want to append to the list of informal units that are understood by WRES, without declaring an alias

[james-d-brown]

Given a commonly occurring informal unit, such as ft^3/s, that is not a UCUM measurement unit
When I want the WRES to understand this informal unit (and hence to allow for unit conversions with it)
Then I want the mapping between informal units and formal UCUM units to happen in a configuration file
So that I can append to the list of informal units without declaring the mapping (aka alias) in each evaluation or requiring a new software version

[james-d-brown]

Context for this is #258.

[james-d-brown]

Currently, the mapping between informal and formal units takes place in Units.java, which is not very convenient. or extensible.

[james-d-brown]

Would also make sense to migrate from xml to yaml as our preferred configuration language.

[james-d-brown]

Have a draft of the yaml schema and working on the reader.

[james-d-brown]

Have the reader implemented and there is an existing unit test that covers the default units (which will now be read from a file on the cp, rather than from code).

Currently working through the shenanigans to ensure that the cp resource is available in all contexts it is needed and none of the ones it is not, notably that it is copied to the /dist/lib/conf of the main app (which is on the runtime cp) and it is not additionally packaged with the wres-datamodel jar, otherwise there would be a conflict. This needs to be exposed to editing by users and /dist/lib/conf is the convenient place for that.

Exposing to service admins would require an additional step because none of the configuration files are directly exposed in a service deployment. For the wres_config.xml, we get around this by exposing the individual options to system property override, which are then hooked in using the podman configs. This would be a bit more fugly in the case of multiple extra unit aliases to add at runtime because the system property would need to be a separated list (map) of key-value pairs that is deserialized (leniently) at runtime. Fugly, but ultimately doable if we need it. The benefit would be that a full deploy could be replaced with a podman only deploy when a new unit alias was desired.

For now, though, I am sticking with exposing this for standalone users.

[james-d-brown]

Progress pushed above. Need to do some top-level integration testing, but otherwise done.

[james-d-brown]

Since this branch starts from #258, I will test #258 and #690 together and then merge in from this branch.

[james-d-brown]

Satisfied that this is working properly. Now possible to add (or remove) default unit aliases in the units.yml, which is placed in dist/lib/conf at gradle build time (and skipped in the wres-datamodel jar, as noted above):

https://github.com/NOAA-OWP/wres/blob/issue690/wres-datamodel/nonsrc/units.yml

[james-d-brown]

Moving back to #258 to test that thoroughly, but will then merge both from this branch as I (albeit mistakenly) branched this one from #258 rather than main. Complete, but on hold until then.