Add es2018.intl ref to es2020.intl

[sandersn]

es2020.intl refers to NumberFormatPartTypes declared in es2018.intl as of #46508.

I'm not sure how to test this; it repros on Definitely Typed in types/ndarray, but when I copy the same files into a compiler test it passes without a problem.

Fixes 3 test failures on DT's overnight run.

Edit: The most recent commit adds a tests to show that the lib change does what it should. But it doesn't show that the bug is fixed -- just that Intl.NumberFormatPartTypes is resolved in a file with /// <reference lib="esnext.bigint" />.

[sandersn]

For comparison, here is the test I tried:

// @Filename: tsconfig.json
{
    "compilerOptions": {
        "lib": [
            "es6"
        ],
        "types": [],
        "noEmit": true
    }
}

// @Filename: ndarray-test.ts
/// <reference lib="esnext.bigint" />

and here is the failing DT package after cutting out unnecessary code:

// @Filename: ndarray-test.ts
/// <reference lib="esnext.bigint" />
// @Filename: tsconfig.json
{
    "compilerOptions": {
        "lib": [
            "es6"
        ],
        "types": [],
        "noEmit": true,
    },
    "files": [
        "ndarray-tests.ts"
    ]
}

Those two files also fail on their own, outside the DT repo.
Triple-slash references work elsewhere in the compiler tests.

[gabritto]

I think in general I don't understand how lib files supposed to work together. In this case, both the es2020.intl and es2018.intl have declare namespace Intl, so those will be merged if the two lib files are present, right? And before this PR and the PR that introduced the type dependency, it was possible to have just the es2020.intl file, no? So won't adding this dependency (1) change the type of things due to merging, or (2) include es2018 declarations that should not be there?

[sandersn]

1. Yes, declare namespace Intl will merge across files.
2. Before this PR, it was possible to have just es2020.intl, and pre-fix: update types for RTF.p.formatToParts() result #46508, the types were actually independent.
3. This PR could change the types, but I'm pretty sure nothing conflicts between es2020 and es2018.
4. In almost all cases, es2020.intl implies the existence of es2018.intl. I guess somebody could make a custom runtime where that's not true. Several other lib files depend on those of previous years, so there's precedent for this.

[sandersn]

I'm going to merge this because I'm confident of the fix, the test at least shows that it does a related, correct thing, and I'm out of time to debug it.