String(Intl)MV should be defined in ECMA-262

[gibson042]

Rather than effectively redefining ECMA-262 StringNumericValue minus RoundMVResult, can we define the syntax-directed operation proposed as "StringIntlMV" in ECMA-262 as e.g. StringMathematicalIdentity returning either an extended mathematical value or -0_𝔽?

ECMA-262 StringNumericValue

<emu-grammar>StringNumericLiteral ::: StrWhiteSpace?</emu-grammar>
<emu-grammar>StringNumericLiteral ::: StrWhiteSpace? StrNumericLiteral StrWhiteSpace?</emu-grammar>
<emu-alg>
  1. Let _x_ be StringMathematicalIdentity of |StrNumericLiteral|.
  1. If _x_ is *-0*<sub>𝔽</sub>, return _x_.
  1. Assert: _x_ is an extended mathematical value.
  1. If _x_ is +∞, return *+∞*<sub>𝔽</sub>.
  1. If _x_ is -∞, return *-∞*<sub>𝔽</sub>.
  1. Return RoundMVResult(_x_).
</emu-alg>

ECMA-402 NumberFormat ToIntlMathematicalValue

 1. Let _literal_ be ParseText(_text_, |StringNumericLiteral|).
-1. If _literal_ is a List of errors, let _mv_ be ~not-a-number~.
-1. Else, let _mv_ be the StringIntlMV of _literal_.
-1. Return _mv_.
+1. If _literal_ is a List of errors, return ~not-a-number~.
+1. Let _x_ be StringMathematicalIdentity of _literal_.
+1. If _x_ is *-0*<sub>𝔽</sub>, return ~negative-zero~.
+1. Assert: _x_ is an extended mathematical value.
+1. If _x_ is +∞, return ~positive-infinity~.
+1. If _x_ is -∞, return ~negative-infinity~.
+1. Return _x_.

(or just use the union of extended mathematical values with {-0_𝔽, NaN} directly rather than introducing the spec enum values)

[sffc]

@romulocintra @bakkot

[sffc]

This is a disruptive editorial change. The current state of how |StringNumericLiteral| works in NFv3 is the result of over a year of work between @romulocintra and @bakkot. I am inclined to wait until after the PR lands in ECMA-402 and then revisit.