ICU4J: Plural rules fail when parsing to IEEE floating point yields incorrect precision

[sven-oly]

Here's an example of a failing test:

{"test_type": "plural_rules", "locale":"mk","label":"3073","type":"cardinal","plural_type":"cardinal","sample":"4.1","hexhash":"da3b0ef6f4fa7630ff1ef134d8976ff6f80dcbbc"}

3073	expected "one", but actual is "other"

The problem is that the string "4.1" is parsed into a double in Java, but it is interpreted by PluralRules as having operands that make it look like 4.1000000 or the like. This precision doesn't represent the originally conveyed fixed decimal in the string, 4.1.

The code to convert between an LDML "exponent string" and a DualStorageBCD (which implements IFixedDecimal) is not public API.

[sffc]

There is a Jira issue for this.

https://unicode-org.atlassian.net/browse/ICU-23093