Update readme with publishing new release steps

[seanmakesgames]

          > What are the next steps we need here to publish a new version?

@SamSaffron since mini_racer version constraint on libv8-node is ~> 16.10.0.0 and this is clearly a bug fix, there is nothing to be done for node-16 on the mini_racer side, only pushing the new node 16 gems.

The typical libv8-node release process (that I should document) is:

• merge whatever PRs are wanted for a release into node-X (here node-16)
• wait for last merge commit CI to be green
• do a Release X.Y.Z.W commit on the branch (like so). It should update changelogs and whatever too.
• wait for CI to be green (it should given the changeset, but sometimes silly mistakes happen!)
• tag that release commit vX.Y.Z.W
• create a release from the tag on the GH page, and attach the CI artifacts of the release commit
• push the CI artifact gems to rubygems

(Most of these can be automated via GH workflows, e.g tag => create GH release + attack artifacts + push to rubygems†. or it can be a manual GH "dispatch workflow")

† this one can also both require and wait for 2FA with some interesting techniques

The degraded libv8-node release process is the same, except (when CI is broken because reasons outside of release blockers):

• merge whatever PRs are wanted for a release into node-X (here node-16)
• wait for last merge commit CI to be as green as possible
• do a Release X.Y.Z.W commit on the branch (like so). It should update changelogs and whatever too.
• build x86_64-{darwin,linux,linux-musl} gems on an Intel machine (resp. make test, make test/linux, make test/linux-musl)
• build arm64-darwin and aarch64-{linux,linux-musl}gems on an Intel machine (resp.make test, make test/linux, make test/linux-musl`)
• build ruby platform gem with rake build
• tag that release commit vX.Y.Z.W
• create a release from the tag on the GH page, and attach the artifacts of the release commit
• push the artifact gems to rubygems

Originally posted by @lloeki in #37 (comment)