Port to Architectury

[MattSturgeon]

This PR ports the project to Architectury, which means both forge and fabric code can be maintained together in a single branch, using the same mappings.

The Architectury docs can be found here.

While 51 files are affected, the majority are just being relocated into the common gradle project. The bulk of the changes are in the various gradle files.

• Moved existing source code into common.
• Define key bindings as static-final fields (as per the current forge branch).
• Use cloth-config on both Fabric and Forge now.
  • Consistent GUI on both platforms and less maintenance for us.
  • On Fabric, we register ModMenu support.
  • On Forge, we register a ConfigScreenFactory extension point.
• Adds a new dependency on the Architectury API.
  • Architectury API is used to register Key Bindings and a ClientTickEvent.
  • We could write our own @ExpectPlatform implementations instead, if fewer dependencies are preferred.
  • Like with cloth-config, the API can be bundled with our jar (done in 65de55804ba06312e7fcc29f415618328da294b4)
• Build system is more or less rewritten from scratch, based on the Architectury templates
• There are common, fabric, & forge mixin configs, however only common is in use. Others left as stubs in case platform-specific mixins are ever required.
• An empty Access Widener is also included. This will be automatically converted to Access Transfoamers on Forge.

Mappings

To minimize changes, yarn mappings are still in use. However Architectury's loom supports using Yarn, Official (Mojang), Parchment, and even MCP.

I noticed you are currently using Parchment on the forge branch.
Would you be interested in changing the main branch too?
Compared with Yarn, which have you found to have better names and JavaDocs?

Modrinth

While this PR removes the need for a seperate forge branch, nothing is changed regarding Modrinth compliance. In the future we could perhaps create a modrinth gradle project that can override sources in common.

Perhaps this could be enabled by a CLI flag, or maybe additional build configurations could be created alongside the normal :forge and :fabric ones.

Neoforge

If you aren't aware, the majority of Forge maintainers have forked Lex's Forge naming their new fork "Neoforge".

Architecury supports Neoforge (and Quilt for that matter) in addition to Lex's Forge, however I'd be surprised if anything is actually incompatible between Forge and Neoforge for our purposes. Just something to be aware of.

Intellij Plugin

Architectury has an Intellij IDEA plugin, which may improve DX slightly. If you're not already using it, you may also want to check out the Minecraft Dev plugin which is very helpful.

CI/CD

While its out of scope of this PR, it'd be great to have Github Actions that automatically run the build for PRs and commits, and release tagged commits.

[hashalite]

This is tremendously helpful, thank you. I was aware this existed but didn't have the time to delve into how it all works.

To answer your question about mappings, I think sticking with Yarn was the right choice, as they seem to be most reliable. Parchment has been somewhat inconsistent with releases. I've had to fallback to Mojang mappings on some occasions.

I think a build configuration for the Modrinth version is a good idea too. I'd be willing to look into that once I have some more free time.

GitHub actions are something I'd like to learn, I currently have zero experience with them. They would certainly make things a lot easier