Add depends property to Mod annotation for conditional entrypoints

[hedgehog1029]

Fixes #201, alternative to #212

This PR adds the ability to specify entrypoints that will only be loaded if the specified mod ID(s) are present:

@Mod(value = "mymod", depends = {"othermod"})
public class MyEntrypoint {
    public MyEntrypoint(ModContainer mod) {
        // for example, now you can depend on OtherModExtension.class safely
        mod.registerExtensionPoint(OtherModExtension.class, () -> new MyOtherModCompatibility());
    }
}

This is implemented by checking against the LoadingModList - entrypoints with depends missing from the loading list are filtered out early.
We enforce in validate that any dependencies specified in the annotation are also specified in the mods.toml - this ensures the mods are loaded in the correct order. No longer enforced, leave it up to developers to choose.

Please let me know if this is a sane approach! Otherwise I suppose I'll have to rethink and move the filtering to a later step.

Unit tests have been added to validate the new behaviour.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

[neoforged-compatibility-checks]

@hedgehog1029, this PR introduces breaking changes.
Fortunately, this project is currently accepting breaking changes, but if they are not intentional, please revert them.
Last checked commit: 3a8905b97c3421ccfdc0e195a6c3d6276c20b335.

loader (:loader)

• net/neoforged/fml/common/Mod
  • depends()[Ljava/lang/String;: ❗ Method was made abstract

[vfyjxf]

why not add a new mod depency type to mods.toml to impl this feature?
Adding new members to Mod annotation look weird, fml currently puts all the metadata in toml

[marchermans]

why not add a new mod depency type to mods.toml to impl this feature? Adding new members to Mod annotation look weird, fml currently puts all the metadata in toml

Personally as a maintainer, I would not like to have a class name in the toml. I already have seen so many times where a class gets renamed and shit breaks. Yeah it takes like 5 minutes to fix, but given that everybody has made that mistake at least once, the time wasted on shit like that is huge, so I would prefer something that follows: one) precedent (which this does because of the dist flag), and two) is potentially something the ide follows (which at least for me string constants are).

If it where up to me it would be some Java language spec default, like a ServiceLoader (because the IDE automatically recognizes it and renames it as well), but that is difficult for us to do. So realistically I think the @mod is the best we can do at the moment.

[vfyjxf]

Personally as a maintainer, I would not like to have a class name in the toml. I already have seen so many times where a class gets renamed and shit breaks.

I mean, we hava mod's'.toml, so we can put different mod in same jar. and don't load this optional EntryPoint when its dependencies not satisfied

something like

[[mods]]
modId = "optional_entrypoint"

[[dependencies.optional_entrypoint]]
modId = "jei"
type = "conditional"
versionRange = "[${jei_version},)"
ordering = "NONE"
side = "BOTH"

and we will ignore optional_entrypoint if jei doesn't exist

[Technici4n]

This is good, thank you for writing the tests as well!

[neoforged-releases]

🚀 This PR has been released as FancyModLoader version 10.0.35.