Mod platform publishing task

[MattSturgeon]

Mod publishing

This PR adds the modpublisher plugin which simplifies the process of publishing to CurseForge & Modrinth.

For an overview, see their readme or their full documentation.

Usage

After creating a release (setting version, release type, patching changelog, committing), you will use the publish task.

publish is Gradle's "umbrella" task, which depends on all publishing tasks. If you only want to publish to modding platforms, you can use publishMod instead, or even publishCurseforge & publishModrinth to publish only to Curseforge and Modrinth respectively.

Note there is also a publishGitHub task provided by modpublisher, however this will do nothing because we haven't configured modpublisher for GitHub Releases (see below). We can't disable the task (which would hide it) because publishMod depends on it.

GitHub Releases

Publishing to GitHub is not covered by this PR. That may be better achieved as part of a CI/CD setup using GitHub Actions/Workflows.

modpublisher has built-in support for publishing GitHub releases, however for our use case the "version" would need to be different and we'll probably need more control...

Secrets

API tokens/keys must be set to actually do any publishing. These can either be gradle properties (curseforge_token & modrinth_token) or environment variables (CURSEFORGE_TOKEN & MODRINTH_TOKEN).

Personally, I'd probably set these as "user" gradle properties by creating a gradle.properties file in the GRADLE_USER_HOME directory (~/.gradle or C:\Users\<USERNAME>\.gradle). Setting up .env is another option.
Definitely do not put them in the project gradle properties, as these get committed to git :joy:!

We'll also want these saved in the repo secrets if we ever setup a CI job to automate publishing.

Published Jars

The appropriate jars are published to each platform; all platforms use the normal build variant (remapJar) except for Modrinth, which uses the output from remapModrinthJar.

Changelog

I haven't added anything to the changelog as this PR only affects internal (dev-facing) stuff, which is already mentioned in the changelog.

The published release will contain the changelog entry relating to the current mod_version.

The changelog section header is omitted, because that should be self-evident from the release the changelog is attached to, however this is configurable and could be included if desired.

Alternative plugins

We initially explored using shedanial's unified-publishing, however we ran into an issue setting "embedded" related mods for the Modrinth platform. Seeing as everything we needed worked on modpublisher & that project appears to be more actively maintained, we decided to use that instead.

Original PR description

Hidden for brevity

This PR implements shedanial's [unified-publishing](https://github.com/shedaniel/unified-publishing) plugin to streamline the curseforge/modrinth publishing process. Publishing to GitHub is not covered by this PR. That may be better achieved as part of a CI/CD setup using GitHub Actions/Workflows. That said, [modpublisher](https://github.com/firstdarkdev/modpublisher) has built-in support for publishing GitHub releases as part of a unified publish task, so we could consider using that instead. API tokens/keys must be set to actually do any publishing. These can either be gradle properties (`curseforge_token` & `modrinth_token`) or environment variables (`CURSEFORGE_TOKEN` & `MODRINTH_TOKEN`). Personally, I'd probably set these as "user" gradle properties by creating a `gradle.properties` file in the [`GRADLE_USER_HOME`](https://docs.gradle.org/current/userguide/directory_layout.html#dir:gradle_user_home) directory (`~/.gradle` or `C:\Users\\.gradle`). Setting up `.env` is another option. Definitely **do not** put them in the project gradle properties, as these get committed to git :joy:! Run using `gradlew publishUnified`. **I haven't tested this**, since I don't have access to your tokens. It's possible I've misinterpreted what is meant by "modrinth id"; currently it's set to `"freecam"`. When testing, I'd recommend changing the `releaseType` to alpha and changing `mod_version` to something like `"TEST"`. Come to think of it, `releaseType` should probably be set as in `gradle.properties`... Any other feedback, questions, etc welcome.

Fixes #134

[MattSturgeon]

@hashalite the next release could be a good opportunity to test this out? You could merge this locally and try using it without actually merging it on GitHub.

I'm happy to help worth through any teething issues with you on Discord, since I can't really test this myself without setting up Curseforge/Modrinth pages.

[MattSturgeon]

I've ported over to modpublisher after our conversation earlier.

Once this is tested/refined further I'll squash the commits, but I've kept it separate for now in-case we decide to revert.

The issue with the fabric project not correctly configuring the requirements might be resolved by this, otherwise try putting it in an afterEvaluate block or we can fallback to moving them to the root gradle script under an if (project.name == "fabric") block.

I set debug = true, which apparently prevents actually publishing. You'll need to remove that line if you want to test actually uploading to modrinth/curseforge.

[MattSturgeon]

Rebased on main, cleaned up a little & added initial changelog code.

If everything works correctly, the published release should contain the changelog section related to the current mod_version.

If the changelog doesn't have a section for that version, then a warning should be logged and the "unreleased" section should be used instead.

[MattSturgeon]

I've polished a bit further and implemented the ability to list additional supported mc versions using supported_mc_versions etc. minecraft_version is always marked as supported.

I was able to do some limited testing by setting a dummy api key & debug=true, everything appeared to work correctly. Not sure if we should merge 6b823cc9dab37b2ae147e7a2e43fdca8978d0013 or not, though? Leaning towards dropping it.

The issue we were experiencing with modrinth dependencies should be resolved, but I can't test that.

The issue with project.version not being defined is now resolved.

[MattSturgeon]

Bumped to modpublisher 2.0.5, so the modrinth slug->id issue should be fully resolved now.

Worked correctly in my tests:

"dependencies": [
  {
    "projectId": "P7dR8mSH",
    "dependencyType": "required"
  },
  {
    "projectId": "mOgUt4GM",
    "dependencyType": "optional"
  },
  {
    "projectId": "9s6osm5g",
    "dependencyType": "embedded"
  }
],

A future modpublisher version will add caching for API requests, since properly supporting slug->id resolution requires calling modrinth's project API a fair bit.