Improve release process and automate creation of a zip archive per target

[happybeing]

The current release process involves:

• build script creates ./dist/prod (for a single target OS)
• contents of ./dist/prod are compressed into a .zip archive with a suitable name
• the zip is tested locally
• if satisfactory, this zip is moved to ./releases
• the repo is tagged with the release (e.g. v0.0.1-rc2) and committed
• the release is pushed (git push --tags v0.0.1-rc2)
• use the git releases feature (ideally using a build cli command) to avoid including blobs in the repo
• delete ./releases
• then remove existing blobs (big zip files) from the commit history using BFG

This needs to be improved, and some stages automated to reduce work and help consistency of process, naming etc.

• First we need a separate subdirectory of ./dist/prod for each target (Linux, Windows etc).

• Secondly, we need to automate the process so that a build-release command cleans ./dist and then builds and creates an archive, and moves the .zip file into ./releases-pending. One option for this is to use package.sh - on second thoughts, we should not use a .sh script but a nodejs script so it can run on all platforms for example.

• Note: some extra files are copied by the build scripts into ./dist/prod and some are still being copied manually (e.g. .node binaries), so this also needs to be automated.

• It would be useful to add support for building a mock package with a -dev included in the zipped archive name.

It would then remain a manual process to move the release from ./releases-pending to ./releases.

I'm not sure whether to .gitignore ./releases-pending. For now I think yes.

---

(Note that the first 'release candidates' should be made on a branch other than master, while the final release candidate should be made after the changes have been merged into master. So merging to master should not happen until a release candidate has been tested and found ready for release. If minor bugs are found after merge to master, further release candidates can be made on the master branch, or a new branch created to resolve more serious issues.)

[happybeing]

UPDATED OP on advice from @b-zee :+1:, to avoid including large blogs (released zips) in the commit history and use github releases feature instead.

[happybeing]

In case it is useful: releast-it is a CLI release tool for Git repos and npm packages

[happybeing]

Closing in favour of issue #3 in new SAFE Drive repo as this repo is no longer in us