Inline GetOperands into PluralRuleSelect

[gibson042]

Following up on #594, I'd like to inline GetOperands into PluralRuleSelect, replacing the Record operands parameter of the latter with the String that is currently input of the former ([[FormattedString]] output from FormatNumericToString). The implementation-defined behavior of PluralRuleSelect would still have access to what is now the input of GetOperands and could deconstruct it in that way if/when appropriate.

         1. Let _res_ be ! FormatNumericToString(_pluralRules_, _n_).
-        1. Let _s_ be _res_.[[FormattedString]].
-        1. Let _operands_ be ! GetOperands(_s_).
-        1. Return ! PluralRuleSelect(_locale_, _type_, _n_, _operands_).
+        1. Return ! PluralRuleSelect(_locale_, _type_, _n_, _res_.[[FormattedString]]).

We might also be able to remove the Number n parameter of PluralRuleSelect, but only if implementations are required to select the same plural category for distinct numbers that format identically, such as "one" for 1.01 when rounding options format it as "1" (which I think is the case but would need confirmation):

        1. Return ! PluralRuleSelect(_locale_, _type_, _res_.[[FormattedString]]).

[ben-allen]

I'm reading through these older issues -- do you think this one is still worth pursuing?

@gibson042

[gibson042]

Yes. It's weird that ResolvePlural takes in a number, formats it to a string, calls out to a dedicated GetOperands operation (i.e., called from nowhere else) for deconstructing that string and reconstructing a number value for it, and then passes the resulting Record to an opaque implementation-defined PluralRuleSelect operation. Because PluralRuleSelect is opaque, implementations already have the freedom to perform the steps of GetOperands within it as warranted.

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2024-08-22.md#inline-getoperands-into-pluralruleselect