Intl.NumberFormat support

[littledan]

It seems like Intl.NumberFormat.prototype.format should support BigDecimal transparently, just as it supports BigInt.

On the ICU level, this should be straightforward, using the same API as BigInt uses.

On a function API level, we have clear precedent with BigInt that we should overload the format and formatToParts methods.

The complexity comes in for options processing: NumberFormat is based on rounding the input, but BigDecimal is all about avoiding implicit rounding. How should that all be handled?

[littledan]

cc @sffc

[littledan]

The complexity comes in for options processing: NumberFormat is based on rounding the input, but BigDecimal is all about avoiding implicit rounding. How should that all be handled?

Maybe this mismatch goes away if BigDecimals are always normalized? The main difference would be in how the default is treated: BigDecimals should omit rounding by default, I think, not round on Number's terms. If rounding options are used explicitly, then great, no mismatch.

[sffc]

I think it would be reasonable if BigDecimal had a different default rounding strategy than Number (or BigInteger), but it should still allow Intl.NumberFormat to apply its own rounding. For example, when rendering a currency, you should obey the currency rounding rules.