Editorial: Simplify NumberFormat

[gibson042]

• Fix id values to align with operation names.
• Refactor spec aliases and parameter types for readability.
• Collapse rounding mode negation data into one table.
• Fold GetUnsignedRoundingMode into ApplyUnsignedRoundingMode

[ptomato]

Would you have time to update the usages of GetUnsignedRoundingMode and ApplyUnsignedRoundingMode in Temporal while this is still fresh?

[sffc]

Hmm. I quite like having a clean separation between RoundingMode (what users specify) and UnsignedRoundingMode (what implementations need). I'm not convinced that essentially replacing the internal enum UnsignedRoundingMode with an internal tuple that pairs RoundingMode with ~positive~ or ~negative~ is an improvement.

[gibson042]

Hmm. I quite like having a clean separation between RoundingMode (what users specify) and UnsignedRoundingMode (what implementations need).

I might agree with you if we didn't make comparisons against the former all over the place, including in many steps in or downstream of NumberFormat PartitionNumberPattern (numberFormat.[[Style]] vs. "percent"/"unit"/"currency", intlObject.[[TrailingZeroDisplay]] vs. "stripIfInteger", numberFormat.[[SignDisplay]] vs. "never"/"auto"/"always"/"exceptZero"/"negative", numberFormat.[[Notation]] vs. "scientific"/"engineering"/"compact", etc.).

I'm not convinced that essentially replacing the internal enum UnsignedRoundingMode with an internal tuple that pairs RoundingMode with ~positive~ or ~negative~ is an improvement.

Well, that's exactly what GetUnsignedRoundingMode does right now. The benefits of instead directly propagating that pair into ToRaw{Precision,Fixed} and ApplyUnsignedRoundingMode are

• Make clear in the definition of rounding modes that only the ceil/floor family need this adjustment when working with absolute values, defining details about the rounding modes in one place.
• Avoid essentially duplicating that table a huge distance away.
• Avoid needless introduction of new entities that basically duplicate the rounding modes anyway.

[sffc]

Just as an anecdote, we found the UnsignedRoundingMode enum useful when implementing ICU4X, and we include it along with the conformance table in the docs.

https://unicode-org.github.io/icu4x/rustdoc/fixed_decimal/enum.UnsignedRoundingMode.html

[gibson042]

https://unicode-org.github.io/icu4x/rustdoc/fixed_decimal/enum.UnsignedRoundingMode.html

I don't have the context to evaluate how (or if) that might be different if the spec had already looked like I'm proposing in this PR, but the "Comparative table of all the rounding modes" at that link includes all 9 user-specifiable ECMA-402 rounding modes and not the current spec enum values produced by GetUnsignedRoundingMode (which makes sense, because the latter are redundant with the former—INFINITY/HALF-INFINITY is just "{ceil,expand}"/"half{Ceil,Expand}", ZERO/HALF-ZERO is just "{floor,trunc}"/"half{Floor,Trunc}", and HALF-EVEN is exactly "halfEven"—due to the respective equivalence of "ceil" vs. "expand" and "floor" vs. "trunc" when limited to non-negative input).