feat: build binaries with node@16

[ghost]

The original goal of this PR was to only migrate our CI and dev environment to node@16. However, I've squashed #2507 into this as our binaries need to use the same Node version as the build environment. So the main visible change in this PR is now the fact that we ship our binaries with node@16.

To Do

• Wait for new pkg release to use latest LTS? https://github.com/vercel/pkg/releases
  • 16.13.1 support in pkg-fetch seems imminent. https://github.com/vercel/pkg-fetch/runs/4695805868
  • Otherwise downgrade to 16.13.0 (and matching npm)
• Upgrade package-lock to use latest pkg.
  • chore: upgrade pkg #2621

Future PR

These steps can be done later as #2599 will change how we current build binaries.

• Add assertions to binary build scripts to enforce node and pkg-fetch version match.
• Ensure the same Node 16 version is used for any automation and documentation.
  • Document this for future upgrades.

Node 16 Binaries

Node 16 is the latest LTS. We already have a Node 16 test pipeline and binaries are tested via production/smoke tests.

Node 16 in Dev and CI

We are currently using Node 14 in development. Let's upgrade to Node 16 LTS before we get left behind.

One major benefit is that darwin/arm64 is only support from Node 16 and above.

Node 14 will still be supported in development to avoid suddenly breaking contributors' environments. We should give people some time to migrate.

Node 16 ships with npm@8. npm@8 is not supported on Node 10. It doesn't fail hard, but does print warnings about it.

npm WARN npm npm does not support Node.js v10.24.1
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm You can find the latest version at https://nodejs.org/

So we'll either need to:

• Downgrade to npm@7 for Node 16
• Wait until we've deprecated and removed Node 10 from our pipelines.
• Go forward with the warnings and work towards removing Node 10.

This PR is going for the last approach so that we're not left behind. Our pipeline still works even with the warnings so it's a matter of removing Node 10 before it stops working.

Failing "Unexpected Error" Tests

Because npx ts-node now prints the deprecation warning on Node 10, I had to change the unexpected errors test to use node -r ts-node/registry so it doesn't pollute stderr assertions. This picked up a minor bug in our error handling module which is fixed in its own commit. The bug wasn't picked up previously because ts-node polluted the process under test with its own error handling, making the test invalid.

Considering various tools may want to hook into error handling and the complexity involved in enforcing the limit, I've removed the handler limit. We can re-introduce the limit when we encounter problems related to not having one.