fix(es2018): add a target and an initial lib

[benbraou]

With this PR:

1. jake LKG is run (first commit)
2. es2018 target and library is added (part of second commit)
3. jake LKG is run again (part of second commit) -

Fixes #20342

[msftclas]

All CLA requirements met.

[mhegazy]

you need to build the new library as well. this is defined in our Jake/gulp files (sorry we have two build systems for now untill we are done with the migration).
JakeFile: https://github.com/Microsoft/TypeScript/blob/8f1cdc9b0c649f1e4fe9d96718be93277baa2ecd/Jakefile.js#L229
GulpFle: https://github.com/Microsoft/TypeScript/blob/8f1cdc9b0c649f1e4fe9d96718be93277baa2ecd/Gulpfile.ts#L168
See 6a737c8 that added esNext target.

[benbraou]

@mhegazy thank you for the review. I am updating my PR accordingly.

FYI, I see that jake LKG generates diagnosticMessages.generated.json file per locale. I think this is related to PR #19308

Therefore, in my PR you will have 2 commits:

1. 'run jake LKG before es2018 addition'
2. 'fix(es2018): add a target and an initial lib' (contains the es2018 lib + jake LKG run a second time)
   Please let me know if I need to squash both commits

[mhegazy]

Thanks! For future references please do not include LKG updates in PRs, they happen as part of publishing or manually directly on master.

[mhegazy]

@benbraou do you want to pick up adding definitions for the new array methods: https://github.com/tc39/proposal-flatMap (a new es2018.array.d.ts file in src\lib) and Promise.prototype.finally https://github.com/tc39/proposal-promise-finally ( es2018.promise.d.ts)

[benbraou]

@mhegazy Thanks you! I got the point to not include LKG updates in future PRs.
Yes, I would love to add definitions for flatMap and promise finally.
Do you want me to create 2 separate issues ? I will be having a look at the implementation tomorrow.

[mhegazy]

Do you want me to create 2 separate issues ?

that would be appreciated. thanks!

[Jessidhia]

(out of scope for this PR but) this pattern repeats often enough that maybe there should be a virtual interface in lib.es2015.iterable.d.ts for this 🤔

interface IterableCollection<K, V = K, I = V> {
  entries(): IterableIterator<[K, V]>;
  keys(): IterableIterator<K>;
  values(): IterableIterator<V>;
  [Symbol.iterator](): IterableIterator<I>
}

Only useful in lib.*.d.ts if interface augmentations are allowed to add extends, though. Alternatively, end the separation between iterable and non-iterable declarations; but that might be undesirable for the folks still supporting IE without polyfills (please stop 🙏😉).

[Jessidhia]

from<T, U, This>(arrayLike: ArrayLike<T>, mapfn: (this: This, v: T, k: number) => U, thisArg?: This): U[]?