Reliably test manual Java unit-constant code, or replace with run-time data parsing

[hugovdm]

We currently have manual implementations of "unitConstants" - for example in3_to_m3, ft3_to_m3, etc - rather than parsing and calculating constants from the units resources.

• Advantages: faster, simpler code.
• Disadvantages: when new constants are added, manual coding has to be done to add these constants to ICU4C and ICU4J.
• Mitigating factor: we don't expect new constants to be added too often.

In ICU4C we have unit tests that at least ensure the code and the constants are in sync. In ICU4J, we currently rely on code review helping ensure the same changes are made.

ICU4J requires more changes than ICU4C though, so I think it worthwhile to add unitConstant freshness unit tests to Java too, as well as to try to have tests that would fail if any of the changes needed for a new constant is missing.

An alternative: more work, but more resilient / less work in the event of CLDR data changes: writing parsing code to pull constants out of the units resource file.

[sffc]

• We should check the number of constants (how many constants there are)
• Port to Java, or add good comments in C++ that J and C should be consistent