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

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.

Start by reviewing the repository's current build and publishing setup, then compare tag-triggered and merge-triggered GitHub Actions for the three release targets: the Gradle plugin repository, Maven Central, and platform-specific CLI binaries. Done means the independent plugin release and the coordinated generator-core/generator-cli releases have an agreed trigger and documented automated workflow.

Written by the indexing model from the issue text.