deps: move to minimum Node 14

[brendankenny]

part of #12614

With Node 17 out and Node 16 LTS planned for next week, this moves us to requiring Node 14 (now the Maintenance LTS) as a minimum requirement.

The changes here are

• updating the references to Node 12 in docs and in package.json, github action scripts, etc
• removing the Node 12 small-icu workarounds introduced in deps: remove intl polyfill #12426 since all versions of Node now supported are build with full-icu by default (it will still log instructions if it's run in a Node purposefully built as small-icu and a non-en-US locale is requested)
• updating a few "TODO: remove once updated to Node x"s, like rmdirSync -> rmSync
• three type updates necessitated by the updated @types/node

[brendankenny]

oh yeah, new stuff :)

Main new features available are nullish coalescing, optional chaining, and private class fields/methods. Node APIs also continue to improve, like the fs.rm used a lot in this PR, as well as better support with async iterables in streams, etc.

As in the past, no need to go out of your way to update old code to use this, we'll just ease into it, updating organically as other code changes land. It's also possible we won't be able to use much of the new JS stuff until we've transitioned off of browserify (see #12134).

[connorjclark]

we are now entering the phase where the master LH readme is misleading for the current release :)

Should we add a giant link at the top of the readme to the last 8.x readme?

[brendankenny]

That's a good question, though I feel like in this case it doesn't reallllly matter. Node 14 became LTS a year ago, I kind of feel like people should be updated anyways :) At worst they'll feel forced to update and LH 8 will still work with it

[brendankenny]

I still don't have a clear feeling for what minimum minor version we should require here. 14.15 is the first LTS 14 release, so it makes sense as a baseline, but there's also been critical security updates since then, so we should definitely not be running that version for testing (and shouldn't be encouraging anyone else to do so either)

Is the intention of Node LTS that since it has long term support with no breaking changes, it's reasonable to always require the latest 14.x?

It's kind of academic right now because unlike Node 12 there haven't (yet) been important feature backports to Node 14 in versions after the first LTS release (like we ended up needing with ESM and Node >= 12.20.0), but it would still be nice to have a coherent vision on if we should consider updating the required Minor version as a breaking change for Lighthouse.

[connorjclark]

I think we can assume the cost of any org updating from 14.x to a higher 14.x is sufficiently low, that we should go higher if we have reason to.

But also, it's hard to know if we have reason to ahead of time, without closely reading all the changelogs since then and thinking real hard about if anything will tie our hands wrt. upcoming refactors we want to do.

so... I'm for putting the latest 14.x release as our minimum.

[brendankenny]

this is from the updated Node types. No longer a global NodeJS.EventEmitter type, it's an interface, so need to extend the actual class declaration.

[brendankenny]

also from the update node types: global is now just type globalThis, so to add to global need to augment the global scope