The spec should call attention to potential instability of |WhiteSpace|

[gibson042]

Because |WhiteSpace| is defined to include «any code point in general category “Space_Separator”», it is not guaranteed to be stable over time and therefore neither are the behavior of String.prototype.{trim,trimStart,trimEnd} or even parseInt/parseFloat/StringToNumber (e.g., the addition of a code point to general category Space_Separator in some version of the Unicode Standard means that implementations incorporating that version will consider it trimmable whitespace while implementations incorporating an earlier version will not). I think this merits an editorial note at the definition of |WhiteSpace| and at the functions and methods it affects.

Along the same lines, we would ideally also refactor StringToNumber to explicitly trim and then delegate to a lower-level operation shared with parseFloat (which already trims and should have the aforementioned note) and with GetSubstitution/ParseTimeZoneOffsetString/etc. (which don't trim and don't need the note).

StringToNumber ( str )

It converts str to a Number, ignoring leading and trailing white space and treating the empty String as 0.

1. Let trimmed be ! TrimString(str, START+END).
2. If trimmed is the empty String, return +0_𝔽.
3. If StringToCodePoints(trimmed) satisfies the syntax of a |StrDecimalLiteral|, return DecimalStringToNumber(trimmed).
4. Let nonDecimalLiteral be ParseText(trimmed, |NonDecimalIntegerLiteral_[~Sep]|).
5. If nonDecimalLiteral is a Parse Node, return 𝔽(MV of nonDecimalLiteral).
6. Return NaN.

DecimalStringToNumber ( str )

It converts a decimal string to a Number.

1. Let literal be ParseText(str, |StrDecimalLiteral|).
2. Assert: literal is a Parse Node.
3. Return StringNumericValue of literal.