🤖 Automatic (or semi-automatic) release process

[canterberry]

In response to #56, the human element of the current release process has led, perhaps inevitably, to an error. This highlights the absence of a formal release process for this package. While releases are not particularly complex, it is still important to codify what that process is, and automate as much of that as possible.

Release Process

Incrementing the Version

1. On the latest master branch, increment the version in package.json.
2. Run npm install to ensure the new version propagates to package-lock.json.
3. Commit the changes with the message "🏁 vX.Y.z Release" (where X.Y.z is the new version).
4. Create a signed vX.Y.z tag (where X.Y.z is the new version).
5. Push both master and the new tag to the main repo.

Publishing

After incrementing the version and pushing those changes to master, wait for the CI build to complete. Then, run the following:

# Replace "vX.Y.z" below with the release tag from above.
git clone --branch vX.Y.z git@github.com:phusion/node-sha3.git
(
  cd node-sha3
  yarn install
  yarn build
  (
    cd lib
    # If publishing a 1.x release, set the tag below to "native" instead
    yarn publish --access=public --new-version=<VERSION> --tag=latest
  )
)

Acceptance Criteria

To deliver this issue, create a PR that automates some or all of the release process as outlined above. This can be in the form of one or more scripts that can be run locally or triggered via a successful CI build. In lieu of automation, an acceptable first step may be to create a PUBLISHING.md document that describes the process.