Change release trigger mechanism

[mtreinish]

Right now qiskit-bot's release automation is triggered by by an authorized contributor pushing a tag to a tracked repo which triggers the changelog generation, github release page creation, etc. However, in practice this has proven to be somewhat error prone, while mistakes in manually tagging aren't common they happen occasionally (typically either tagging the wrong branch or the wrong commit). These mistakes are avoidable though if we just have qiskit-bot do the tagging.

A workflow I've been thinking about since the aer 0.4.2/0.5.0 release (which was caused by an admin on aer at the time tagging 0.4.2 on master instead of the stable branch) is to trigger the release automation from the release prep PR somehow and let qiskit-bot do the tagging (either directly or via github's release api). The two trigger conditions I'm debating between are either a PR merge with a release tag, or a user comment like @qiskit-bot release on a merged PR. I'm leaning towards the latter because it enables us to limit the users via configuration on who are allowed to trigger a release (more users are allowed to tag a PR than just those with write permissions) and it's more explicit in behavior.

Assuming we go with a comment trigger the expected behavior here would be adding a config field to list the authorized usernames on a repo, then on each PR comment check for the expected trigger comment text (probably just @qiskit-bot release) that will then trigger the tag creation from the sha1 of the merged commit for the pr (merge_commit_sha in the PR details). The rest of the release workflow should be the same.

[mtreinish]

Thinking about this a bit more, if we did the tagging locally instead of via the github release api we probably should create a gpg key for qiskit-bot so the releases are signed by the bot key