Update CO2CarDemo based on CLDR

[keilw]

The CLDR system already defined LITER_PER_KILOMETER, LITER_PER_100KILOMETERS and MILE_PER_GALLON as Unit<Consumption<Volume>>. This overlaps with the declaration of the quantity FuelConsumption in the energy module. Update the CO2CarDemo accordingly by using the CLDR units if possible. Should there be a problem with Consumption, we might have to reconsider it and move the FuelConsumption type to systems-quantity so it may be used by CLDR.

[andi-huber]

regarding CLDR units:

Avoid use of double type factors when defining Units, instead use integers or rational numbers (in case the definition allows us to). eg:

• https://github.com/unitsofmeasurement/uom-systems/blob/3a6611af205db93020dad8656c06415adbe0c016/unicode/src/main/java/systems/uom/unicode/CLDR.java#L536
• https://github.com/unitsofmeasurement/uom-systems/blob/3a6611af205db93020dad8656c06415adbe0c016/unicode/src/main/java/systems/uom/unicode/CLDR.java#L161

regarding Consumption:

Defining consumption based on volume per length might be considered bad practice, because for any given substance consumed, it's volume is dependent on its temperature and pressure. So to improve on that one could define consumption as mass per length, but then this is not generic enough, because, one could also think of consumption as being of units mass per time.

[keilw]

@andi-huber Thanks for the update, so I guess you suggest to go with the FuelConsumption type then and add it to systems-quantities to allow using it for CLDR? Based on the discussion we also had in https://github.com/unitsofmeasurement/uom-systems/issues/176, that sounds reasonable because it depends on multiple factors. I would not remove Consumption, if we come back to it with other quantities like Electricity, not sure if that also has a similar side-effect, but I guess there should be some that are neutral. I imagine there are also other use cases like "Data consumption" in the cloud that justify its existence.

Please create a PR against CLDR with the precision changes.

Once we took the FuelConsumption into consideration, do you think that'll solve the problem in https://github.com/unitsofmeasurement/uom-systems/blob/master/unicode/src/test/java/systems/uom/unicode/FuelConsumptionTest.java (https://github.com/unitsofmeasurement/uom-systems/issues/177), or could that also have something to do with using double? Note, Indriya has a major Jigsaw problem, so let's be extra careful with solving any functional problems beyond 2.0.4 before that is addressed, see https://github.com/unitsofmeasurement/indriya/issues/306.