Replace new tags as the trigger for making a new pip release

[nightlark]

Using new tags as a trigger for making a new pip release has issues with post release version tag interfering with the post release tag used as part of the Python versioning.

Another downside of the current set up, is that it doesn't work with multiple packages -- there is no way to release a post update to one package but not another.

An external trigger is needed -- either a comment on an issue (or issue name?) or a dispatch event (with some online dashboard to send the event) that can be used to specify which commit/tag should be packaged, and which packages.

[nightlark]

A few more ideas for this:

• when a version update dispatch event arrives and triggers a build (detect from file changed in commit?), ping the HELICS+ server to check the uploaded TestPyPI pre-release and if it looks good, trigger a full release
• dispatch event to trigger releases with specific version/package names seems better than an issue comment (also avoids the rebuild of the master branch when making a github release)
• when a full release is made, ping the HELICS+ server to verify that the expected packages are there; if they are, trigger version updates for packages that need to use other packages (conda)