GitHub Release publishing tweaks

[MattSturgeon]

Motivated by #7, introduce some basic control over how GitHub Releases are published.

• Allow configuring whether missing/existing releases are created/updated
• Allow publishing to a tag that is different to version

I'm fairly unfamiliar with your codebase, so feel free to propose changes, push commits here, or discard this PR in favour of your own implementation.

[MattSturgeon]

I think we should also add a createGithubTag option, checks if the tag exists before creating a release.

This would be similar to the gh CLI's --verify-tag option.

[hypherionmc]

I think we should also add a createGithubTag option, checks if the tag exists before creating a release.

This would be similar to the gh CLI's --verify-tag option.

Sounds good. Could be useful to add

[MattSturgeon]

All points addressed.

Let me know if there's any other changes, or if you'd like any of these options included in the testprojects.

It'd also be nice to expose configuring whether the release is a draft, and the "commitish" used when creating a new tag. Perhaps in a future PR...

[MattSturgeon]

How should multi-project builds play into this?

As is, if a user configured updateGithubRelease = false, for example, only one of their projects would publish. It'd be undefined which one, too...

We could document this somewhere. Unless there's a better approach where some checks could be shared across projects or something?

If this is opening up a can of worms, maybe we scale this PR down to just githubReleaseTag and postpone the boolean properties?

EDIT: I'm wondering if exposing some function properties would be a better approach.

E.g. shouldCreateRelease(ctx) and shouldUpdateRelease(ctx). Having a context object would allow the user to implement custom logic.

Similar provider functions could be used for the updated values, such as release body, display name, etc... 🤔

[hypherionmc]

Maybe it could make more sense to have a dedicated GitHub section, similar to what we have now for overriding the values of the additional files on curse.

The behavior would then be to use the default configuration as before, but anything under that section would override the default values.

Multiproject usage shouldn't be a major issue, as the plugin is usually configured per project, rather than once in root.

[MattSturgeon]

Maybe it could make more sense to have a dedicated GitHub section

Agreed, I've attempted that in my latest push. Not sure if it's correct or not though, wasn't able to test.

[hypherionmc]

I'll take a look over everything tonight. Day is insanely crazy. Thank you :)