Investigate number parser reuse

[annevk]

I vaguely recall @ayg complaining ages ago about duplicating the parsers we already have for ECMAScript and Web IDL. I think the idea against that was that HTML should in theory be able to go beyond the limits imposed by those parsers. That might still be a worthwhile goal of sorts, but I don't think there's a good reason to have multiple specifications define ConvertToInt and the like.

[domenic]

I don't think we should ask JS to change here. So it's a question of whether HTML can change to JS's semantics.

I think this might be a normative change, but probably one we could get away with.

For integers, the algorithms to compare are:

• https://html.spec.whatwg.org/#rules-for-parsing-integers
• https://tc39.es/ecma262/#sec-parseint-string-radix (with radix = 10)

These definitely seem different, including e.g.:

• the definition of white space that is used
• how much leading/trailing garbage is allowed
• ES's algorithm allows implementation-defined results after 20 digits (!)
• ES's algorithm converts the results to floating point using 𝔽.

For floats:

• https://html.spec.whatwg.org/#rules-for-parsing-floating-point-number-values
• https://tc39.es/ecma262/#sec-parsefloat-string which quickly delegates to https://tc39.es/ecma262/#sec-runtime-semantics-stringnumericvalue
• https://tc39.es/ecma262/#sec-stringtonumber which does the same

I haven't investigated the differences there.