define release process and add gh action(s) to support automated releases

[PerryAJ]

I'd like to establish a proper release workflow for publishing:

1. the module plugin to the Gradle plugin repo, when there is a new (non-SNAPSHOT) version
2. the module generator-core lib, to maven central, when changes have been merged into master
3. to this repo's 'Releases', the generator-cli native-image binary for Linux, Mac and Windows platforms.

TBD - the mechanics of the release. One idea would be to use specially formatted git tags as the 'trigger' for when a release should occur. For example, pushing a 'plugin-vX.Y.Z' tag to the repo might result in running a 'publish plugin' action. We could use similar processes for publishing each of the core and CLI releases.

Alternatively, we could start targeting a 'dev' branch for PRs, and then use merges into 'master' as the signal for releasing.

The primary requirements for whichever process we choose:

1. The version of the generator-core and generator-cli may track with each-other (meaning, releasing one necessitates a release of the other), but do not necessarily need to
2. the module plugin must be able to version and release independent of the generator-core and generator-cli projects.

Feel free to make suggestions.

[brianeray]

This'll be IGN-9408.