Editorial: Fix ecmarkup warnings

[gibson042]

warning: trailing spaces are not allowed (spelling) at spec/datetimeformat.html:152:54:
  150 |           1. Assert: _hour12_ is *undefined*.
  151 |         1. Set _dateTimeFormat_.[[HourCycle]] to _hc_.
> 152 |         1. Set _formatOptions_.[[hourCycle]] to _hc_. 
      |                                                      ^
  153 |         1. Let _matcher_ be ? GetOption(_options_, *"formatMatcher"*, *"string"*, « *"basic"*, *"best fit"* », *"best fit"*).
  154 |         1. Let _dateStyle_ be ? GetOption(_options_, *"dateStyle"*, *"string"*, « *"full"*, *"long"*, *"medium"*, *"short"* », *undefined*).
  155 |         1. Set _dateTimeFormat_.[[DateStyle]] to _dateStyle_.


warning: literal Number or BigInt values should be followed by <sub>𝔽</sub> or <sub>ℤ</sub> respectively (spelling) at spec/numberformat.html:196:27:
  194 |         1. If _x_ is *NaN*, then
  195 |           1. Let _n_ be an implementation- and locale-dependent (ILD) String value indicating the *NaN* value.
> 196 |         1. Else if _x_ is *+&infin;*, then
      |                           ^
  197 |           1. Let _n_ be an ILD String value indicating positive infinity.
  198 |         1. Else if _x_ is *-&infin;*, then
  199 |           1. Let _n_ be an ILD String value indicating negative infinity.


warning: literal Number or BigInt values should be followed by <sub>𝔽</sub> or <sub>ℤ</sub> respectively (spelling) at spec/numberformat.html:198:27:
  196 |         1. Else if _x_ is *+&infin;*, then
  197 |           1. Let _n_ be an ILD String value indicating positive infinity.
> 198 |         1. Else if _x_ is *-&infin;*, then
      |                           ^
  199 |           1. Let _n_ be an ILD String value indicating negative infinity.
  200 |         1. Else,
  201 |           1. If _numberFormat_.[[Style]] is *"percent"*, let _x_ be 100 × _x_.

[gibson042]

@sffc There is an unrelated problem here: FormatNumericToString expects a Number or BigInt value, while x is a mathematical value that AFAICT might suffer output-affecting lossiness if converted.

And similar problems in later steps (in which whether or not x is a mathematical value is dependent upon whether or not the original input was finite!):

1. GetNumberFormatPattern performs incoherent comparisons on its input, _x_ is 0 or _x_ > 0 is only valid for mathematical _x_ while _x_ is *NaN* can only be true if _x_ is a Number.
2. Likewise, PartitionNotationSubPattern seems to expect a mathematical x but then compares it to infinities and *NaN*.

I think the best fix would be updating FormatNumericToString/GetNumberFormatPattern/PartitionNotationSubPattern/etc. to accept new parameters allowing them to identify special non-mathematical Number values such as negative zero and infinities and NaN.

[sffc]

LGTM and after this is merged I'll need to merge these changes into NFv3