Replace the Visual Effect system

[sovdeeth]

Problem

Visual effects were on their last legs. The increase in particles requiring data and constant changes in what effects/particles existed meant that visual effects was not up to date, had problems with serializing values, was lacking functionality, and was horribly documented. Users were nearly always using SkBee's or skript-particle's particle syntaxes instead, as they featured fully functional syntax for setting offsets, data, and were reliable.

Solution

This PR separates visual effects into three categories: Game Effects (Effect.class), Entity Effects (EntityEffect.class), and Particle Effects (Particle.class, ParticleBuilder.class).

Game Effects.

Game effects are rather powerful effects to display particles, play sounds, or both at once. They make it easy to replicate existing ingame effects, like waxing, dispenser activations, turtle eggs cracking, and more. Very little changes from visual effects except that effects that do not require data are automatically supported, while data-requiring effects have a specific expression with documented patterns. This should alleviate the lack of docs for visual effects, who depended entirely on lang file entries for patterns and therefore were not documented.

Entity Effects

Entity effects do not require data and are therefore much simpler than game or particle effects. This PR mostly maintains the system from Visual Effect, though modernised with EnumClassInfo. The separation into its own classinfo, though, allows better parse time type checking and ensures entity effects aren't played at locations and are instead played at acceptable entities.

Particle Effects

Particle effects are the most complex and required the most work. Simple particle effects without data are now parsed via an EnumClassInfo and the data-requiring ones are registered in an expression like game effects. The particle system is now backed by a new ParticleEffect class, though, which extends Paper's ParticleBuilder class to provide storage of type, data, offset, speed, count, recipients, and more. This allows Skript to provide an easy to use and powerful particle api to addons without each needing its own wrapper class.

Since particles vary in behavior depending on count being 0 or 1+, ParticleEffect provides an ease of use function to set the particle distribution (the behavior of offset when count is 1+) which sets count to 1 if it is 0. You can also check whether it is in distribution mode. For behavior when count is 0, child classes of DirectionalEffect, ScalableEffect, and more exist to provide api to handle their behaviors, such as setting velocity or scale. These likewise set count to 0 if it is not already 0. This behavior is mirrored in the syntax, where velocity of {particle} is not set if count > 0, and setting it will set count to 0. This should provide the most intuitive and natural experience for the user, as setting the velocity will ensure the offset is treated as velocity, while setting the distribution will likewise ensure the offset is a distribution.

Drawing

Drawing all three effect types is handled through a single EffDrawEffect syntax which provides the extra options for each. This will likely be changed to a type property syntax in the future.

Testing Completed

EffDrawEffect.sk

Supporting Information

A helper class was added to yggsdrasil to aid in registering serializers for external classes without classinfos.

Some of the syntaxes will likely be replaced by type properties in a later PR.

Significant breaking changes as Visual Effects will be removed and patterns will change for nearly all effects.

---

Completes: #8157 #7932 #5702 #5146 #4196
Related: none

[APickledWalrus]

This look really good! Most of my comments are around formatting/code tweaks. The design itself looks fantastic.

[APickledWalrus]

Just a few minor things. I think just using Origin (or directly importing ModuleOrigin) for the register methods should be okay.