CI: add binary workflows

[jesec]

Linux: https://github.com/jesec/pkg-fetch/actions/runs/711723135

Windows: https://github.com/jesec/pkg-fetch/actions/runs/711723405

• Node < 14 does not support cross compilation for win-arm64

macOS: https://github.com/jesec/pkg-fetch/actions/runs/711723492

• There is no support for cross compilation on macOS. Plus, the signing issue with Apple Silicon: https://github.com/jesec/pkg-fetch/releases/tag/v2.7 .

This should allow us to release 3.0.

@leerob , after we merge this change, please:

1. Bump and tag version. Build and release to npm.
2. Go to Actions and run binary workflows.
3. Fetch the binaries from Actions after workflows finish.
4. Rename from built-* to node-*.
5. Upload them to a v3.0 release. (strictly vMAJOR.MINOR here. no patch. patch releases are not expected to change binaries)

Users of pkg are not going to be affected by the new pkg-fetch release at this moment, as pkg uses a pre-defined version of pkg-fetch.

With a new release of pkg-fetch and binaries ready, we can go back to pkg, bump the pkg-fetch, and run the test suite. If everything goes well, we can do a release there, but we can also wait a while.

I plan to add support for a fully static (Linux) variant soon. Additionally, I think we can tweak the configure arguments of Node to make the binaries smaller. And, should we strip (debugging symbols from) binaries?

[robertsLando]

Why don't just create a draft release now and instead of uploading artifacts directly upload tags to that release?

[leerob]

I'm all in favor of whatever reduces the amount of manual work needed. Less chance for me to make mistakes 😄

[jesec]

It is indeed possible to add workflows that create and upload binaries to a release automatically.

However, that may not be desired in some cases. For instance, we may want to coordinate release with npm side, and we may not want to override existing release assets before we actually do a release.

This change definitely makes things significantly easier. Maintainers no longer have to spend (tens of) hours with different build configurations and machines. Though, we still have some relatively trivial jobs to do: fetch binaries from Actions, rename, and upload to Releases.

[robertsLando]

I would (at least) remove the need to rename them, I'm still not 100% sure about the manual downlaod/upload as it takes some (useless) time to download ad upload them... I think that once we have them on assets we could decide if drop or keep them. Maybe we could add a check and if the asset is already present on relase don't override it but upload as artifact or with a (2) at the end so we can later decide which one to keep. Manual rename could have some typos and I think we should make this part almost all automated

[jesec]

Reply to all Node 8 comments:

Because Node 8 is still in the patches/. If we don't want to support it, we have to remove it from the patches/.

Per our previous discussions, we may want to allow at least one recently deprecated Node version.

[robertsLando]

LGTM

[robertsLando]

@leerob Let's go on with this as it is a must have