Add toLocaleString

[jessealama]

Here we add toLocaleString to both the main specification (spec.emu) and the Ecma 402 part (intl.emu). As with Number.prototype.toLocaleString (which we're just copying), the main specification essentially delegates to the 402 part, with the recommendation to just use no-argument toString as a fallback. In the 402 part, we declare that toLocaleString should just format the decimal as-is, including any trailing zeroes.

This decision makes toLocaleString align with Intl.NumberFormat.prototype.format, leaving open the possibility that toString and toLocaleString may return different strings (because we are, currently, removing all trailing zeroes by default in toString but keeping that all in, by default, in toLocaleString). We are open to revising this decision later.

CC @sffc

[nicolo-ribaudo]

leaving open the possibility that toString and toLocaleString may return different strings

Is this surprising at all? On my machine 1234567..toLocaleString() returns "1,234,567", while 1234567..toString() returns "1234567".

[jessealama]

leaving open the possibility that toString and toLocaleString may return different strings

Is this surprising at all? On my machine 1234567..toLocaleString() returns "1,234,567", while 1234567..toString() returns "1234567".

The potential non-alignment has to do with trailing zeros. The current thinking is that toString, with no arguments, will remove trailing zeros but Intl.NF.prototype.format (with no further arguments) will preserve them.