Proposal: Merge unified multi-version and multi-loader branch

[flier268]

Hi, I have been working on a branch that consolidates the older Minecraft-version branches and adds unified support for multiple loaders. I would like to ask whether this direction would be acceptable for upstream, and whether you would be open to reviewing a PR for it.

The branch is based on the current mc/1.21.1 line and reorganizes the project around a Stonecutter-based multi-version setup, so the older supported Minecraft versions can be maintained from one shared codebase instead of separate long-lived branches.

Main changes

• Consolidates the old version branches into a unified multi-version project structure
• Adds support for Fabric, Forge, and NeoForge
• Introduces a Stonecutter-based build layout for maintaining multiple Minecraft versions
• Moves shared registration, adapter, runtime, spawn-checking, storage, and client rendering logic into common layers
• Adds a diamond-base Mega Torch variant
• Adds visible working-range rendering for torches
• Adds per-light settings, including directional range configuration
• Adds simple access control / permission handling for light configuration
• Updates CI/build support for multi-version builds and publishing
• Fixes several compatibility issues across older versions and loaders

Motivation

At the moment, support for older Minecraft versions and different loaders is spread across separate branches. That makes feature work and bug fixes harder to keep consistent across versions.

This branch tries to reduce that maintenance cost by keeping the common behavior in shared code, while isolating Minecraft-version and loader-specific details behind adapters or Stonecutter conditionals where needed.

Notes

I understand that this is a fairly large change set. If the overall direction is interesting, I can adjust the contribution format to make it easier to review, for example by:

• Splitting the work into smaller PRs
• Submitting the multi-version / multi-loader infrastructure first
• Submitting the diamond-base torch and range-visibility features separately
• Renaming or restructuring code to better match the upstream style
• Adding more documentation or validation notes for supported versions/loaders

Would you be open to this kind of consolidation being merged upstream?

[Xalcon]

I've tried this several times in the past and cross version conflicts simply made this more complicated than simply having them in dedicated branches. I'm even considering removing the multiloader concept entirely and maintain dedicated repositories per modloader to have more targeted implementation approaches than these attempts at generalizing the implementation in a common module that required so much additional boilerplate code that it reminded me of enterprise software. I've spend enough time getting common code generalized enough to have it work with multiple mod loaders.

I'll stick to git worktrees, they give me similar benefits without the drawbacks of a convoluted repository.

[flier268]

You can refer to my solution: https://github.com/flier268/TorchMaster