Add new MobEffect constructor that allows specifying a particle factory

[ChampionAsh5357]

Closes #1558

Currently, the mob effect can specify a ParticleOptions to handle what particles should be displayed. However, as the particle options may contain modded entries that may not exist at the time of the mob effect initialization, the options need to be deferred somewhat. This is normally done with a supplier, but since there is already a factory that the option is delegated to, I opted to simply expose it as a parameter.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

Last commit published: 1f1fb37123677da07b215b54e5c64684af26b170.

PR Publishing

The artifacts published by this PR:

• 📦 net.neoforged:neoforge:21.1.67-pr-1578-fix-mobeffect-particleoptions
• 📦 net.neoforged:testframework:21.1.67-pr-1578-fix-mobeffect-particleoptions

Repository Declaration

In order to use the artifacts published by the PR, add the following repository to your buildscript:

repositories {
    maven {
        name 'Maven for PR #1578' // https://github.com/neoforged/NeoForge/pull/1578
        url 'https://prmaven.neoforged.net/NeoForge/pr1578'
        content {
            includeModule('net.neoforged', 'neoforge')
            includeModule('net.neoforged', 'testframework')
        }
    }
}

MDK installation

In order to setup a MDK using the latest PR version, run the following commands in a terminal.
The script works on both *nix and Windows as long as you have the JDK bin folder on the path.
The script will clone the MDK in a folder named NeoForge-pr1578.
On Powershell you will need to remove the -L flag from the curl invocation.

mkdir NeoForge-pr1578
cd NeoForge-pr1578
curl -L https://prmaven.neoforged.net/NeoForge/pr1578/net/neoforged/neoforge/21.1.67-pr-1578-fix-mobeffect-particleoptions/mdk-pr1578.zip -o mdk.zip
jar xf mdk.zip
rm mdk.zip || del mdk.zip

To test a production environment, you can download the installer from here.

[Shadows-of-Fire]

Yeah I think this is the best solution. Unfortunately, ParticleOptions is a bit of a mess, since MobEffect is dependent on it, but it is natively dependent on both Item and Block. In the vanilla order, MobEffect is before both Item and Block, so trying to shuffle the registry order around for correctness would be incredibly annoying.

[Shadows-of-Fire]

We should add a javadoc comment to this constructor, not necessarily to inform the users of the parameters (they're pretty self-explanatory), but do to the following:

1. Inform the user this is a patched-in ctor (i.e. add a Neo: header)
2. Inform the user that they should use this constructor over the ParticleOptions one if using a ParticleOptions that depends on other registry entries.