Going through strings for numerical operations

This proposal still suffers from going through string representations for numerical computations. We should absolutely avoid ending up in a situation where we need to do computations on strings. It's not something we want to support.

In particular I would argue that

1. relying on a string rendering of a number to store precision is a mistake,
2. allowing any computation on values stored in strings is a mistake.

These design problems surface e.g., in rules like for convertTo, where we basically have to do an ad-hoc variant of the constructor spec and do a full roundtrip through 3 representations, to support encoding the precision.

Especially in convertTo it is very questionable if we should allow converting to a precision that is higher (after conversion!) than the input precision. With the current design we cannot even detect this problem, because we cannot know if the Amount was created with a lower precision, or if the user just happened to pass a particular exponential string to the constructor.

In general I think it's bad style to use intlMV in 262 for anything that is continuing to use the value as a numerical value. This creates a dependency that is imho not warranted and might cause issues down the line, even if we fix the most problematic cases, like the one above. Even relatively simple operations like toString are currently stringifying, re-parsing and re-stringifying. At the very, very least this must come with a proof of existence for an efficient implementation without the intermediate step.

Start by reviewing the proposal's convertTo, constructor, and toString rules, along with the uses of intlMV described in the issue. Done should mean the design no longer requires numerical computations to pass through string representations and can address precision provenance without the current roundtrips.