Editorial: Remove ToNumber's note re surrogates (#1554)

The note says that "the result of ToNumber will be *NaN*
if the string contains any [surrogate] code units,
whether paired or unpaired."

However, if Unicode were to define a non-BMP code point
with General_Category=Zs, that would qualify as <USP>
and thus WhiteSpace and StrWhiteSpaceChar, in which case
the note would be rendered false. That is, the ToNumber
procedure would continue to work, and would result in
non-NaN values for some strings containing surrogates.

(And if you think that the ES spec doesn't need to concern itself
with such future possibilities, note that ES 6 (2015) changed/clarified
the semantics of String.p.trim et al for precisely this case,
to say how they would deal with non-BMP white space.)

Given that the note could be invalidated by a future
edition of Unicode, I think it's a bit risky to keep it in.

spec.html

@@ -4402,9 +4402,6 @@ <h1>ToNumber ( _argument_ )</h1>
       <emu-clause id="sec-tonumber-applied-to-the-string-type">
         <h1>ToNumber Applied to the String Type</h1>
         <p>ToNumber applied to Strings applies the following grammar to the input String interpreted as a sequence of UTF-16 encoded code points (<emu-xref href="#sec-ecmascript-language-types-string-type"></emu-xref>). If the grammar cannot interpret the String as an expansion of |StringNumericLiteral|, then the result of ToNumber is *NaN*.</p>
-        <emu-note>
-          <p>The terminal symbols of this grammar are all composed of characters in the Unicode Basic Multilingual Plane (BMP). Therefore, the result of ToNumber will be *NaN* if the string contains any <emu-xref href="#leading-surrogate"></emu-xref> or <emu-xref href="#trailing-surrogate"></emu-xref> code units, whether paired or unpaired.</p>
-        </emu-note>
         <h2>Syntax</h2>
         <emu-grammar type="definition">
           StringNumericLiteral :::