Add tests for calling Intl.PluralRules with BigInts

[anba]

Tests for tc39/ecma402#1026

[anba]

cc @ben-allen

[anba]

The String tests already pass in JSC/V8/SM, only the BigInt tests require implementation work.

I didn't add tests for large BigInt inputs, because ICU4C internally coerces everything to double, which leads to false results. This makes testing difficult when using ICU4C. For example:

js> new Intl.PluralRules("fr").select(20000000000000001n)  
"many"

"many" is incorrect, it should instead be "other" (cf. https://github.com/unicode-org/cldr/blob/410fa03400aab2c32e90278af9310a93bed2b3ce/common/supplemental/plurals.xml#L120).

(getPluralOperand returns double in ICU4C, e.g. in https://searchfox.org/firefox-main/rev/81cd862538be1cf95842a2ddfb7a5dd22c11ab25/intl/icu/source/i18n/plurrule.cpp#960.)

ICU4X gets this correctly (Output: category: Other):

use icu::locale::locale;
use icu::plurals::{PluralOperands, PluralRules};

fn main() {
  let pr = PluralRules::try_new(
    locale!("fr").into(),
    Default::default()
  ).expect("locale should be present");
  
  let operands: PluralOperands = "20000000000000001".parse().expect("Failed to parse to operands.");
  println!("category: {:?}", pr.category_for(operands));
}

[ptomato]

Probably best to still add large BigInt tests, even if they're in a separate file so that ICU4C-using implementations can skip them?

[anba]

It looks like even ICU4X supports at most 18 digits, so larger BigInts can't be tested there either.

PluralRuleSelect doesn't require any specific minimum digits limit, so I'm not even sure test262 can/should have tests for this.

[ptomato]

Maybe someone more familiar with the API could weigh in, but that sounds like a limitation not present in the spec that would be fine to have a failing test for — just because no engine implements it correctly isn't a reason not to test it.

(OTOH, if it's something more equivalent to "strings longer than 4 GB" then it's probably diminishing returns to have tests for it.)