Create a release GH workflow

[displague]

In order to avoid situations like #249, GH workflows should be used to tag new releases.

The release workflow should take a semver version, update libraryVersion in packngo.go, and tag the release.

Moreover, the RELEASE.md steps should be followed in the GH workflow, and the RELEASE.md should be updated to tell maintainers to dispatch the GH workflow.

[t0mk]

They somehow do this in Linode:

https://github.com/linode/linodego/blob/master/.github/workflows/release-drafter.yml

[displague]

If we use release-drafter, we will need a job in that workflow that runs just before release-drafter to do the version bump.

While we are at it, we could change const libraryVersion in packngo.goto var Version in version.go, this will make it easier to replace in automation, make the variable available to users, and make the variable something we can change at build time if needed.

I was thinking that the version + release would be part of a dispatched action, with prompts. ("What version do you want to release?" "What commish (default: master)?".

If we have to push a tag to master manually for release-drafter to trigger, we'll be just as likely to forget to update the version stamp.

---

A simple solution might be to use version.go (as above) and have make release attempt to tag a release using the version
from that file. If the tag already exists, make release would fail.

---

I think I still prefer an automated workflow, we can likely make it smarter and take hints about what version to deploy. Maybe we need to keep "v0.8.0-beta" (where 8 is +1 of the current release) in version.go. Automation can remove the beta on release and then increment the number on the commit that follows the release.

[displague]

Since #281, we don't need to update the version stored in version.go.

This means that tags can be applied at any time, using the GH UI. Release automation would be beneficial for drafting release notes. For this, we should consider workflows that parse well-formatted commit messages and perhaps try to enforce that commit format to some extent.