Refactor ApelClient code

[DarthSharkie]

• [x] Extract from ApelClient to a payload handler
• [x] See if ApelRenderer can be implemented client-side

Edit:

This is a runaway train! Once the point computation was done (basically copied from ApelRenderer default methods), it became clear that the point computation could be done by Instruction instances. I think the path forward looks like this:

• [x] Add computePoints to Instruction interface. Implement for all (or throw UnsupportedOperationException for things like PType and Frame that don't have points).
• [x] Cache the computed points, then rotate and translate with quaternion and addition.
• [x] The server renderer (DefaultApelRenderer) should use the same caches, and just have a different drawParticle implementation.

[DarthSharkie]

Both of these are possible and done. Commit references to follow, once they're stable (too much local rebasing/reworking).

[DarthSharkie]

This is a runaway train! Once the point computation was done (basically copied from ApelRenderer default methods), it became clear that the point computation could be done by Instruction instances. More steps added to top comment!

[DarthSharkie]

Instruction point computation and caching is done and working.

[DarthSharkie]

Commits:

• Extract payload handler: https://github.com/GitBrincie212/Apel-Mod/commit/c504fad9cfe5c3778b459208e3951f116fe4ea1e
• Implement ApelRenderer client-side: https://github.com/GitBrincie212/Apel-Mod/commit/c504fad9cfe5c3778b459208e3951f116fe4ea1e
• Add computePoints to Instruction: https://github.com/GitBrincie212/Apel-Mod/commit/cfed8b3e59a3d8d7a39c6ad4bf92772dff0af760
• Cache/rotate/translate points in client renderer: https://github.com/GitBrincie212/Apel-Mod/commit/e3f86588f30e5f30108b26aa04da8fc6341c587a

Merged in https://github.com/GitBrincie212/Apel-Mod/pull/22.

[DarthSharkie]

Common base renderer: https://github.com/GitBrincie212/Apel-Mod/pull/23.

[DarthSharkie]

As I worked on this, realized that the draw... methods in ApelRenderer are turning into a "unit" shape with scale, rotate, and translate operations performed. This doesn't cover line-based shapes (AFAICT), but it does cover 3D equation-defined shapes. Actually, on second thought, all lines can be made into unit vectors...but is that worth it? Probably not.

Their draw... methods should be drawShape(ParticleEffect, amount, scale, rotate, translate). Scale can be float, Vector2f, or Vector3f depending on shape, but should probably just be Vector3f when implementing, since that's what the Matrix4f will want when using translateRotateScale. Allocating that in ParticleObjects consistently would allow for ease of profiling (due to consistency) vs. conditionally allocating in ApelRenderer and implementations.

Caching can then be done based on the (shape, amount) tuple, and Matrix4f#transformPosition(point) called on each point.

[DarthSharkie]

If the unit shapes are computing, the computePoints() method could do the caching internally to the Instruction...need to consider if this is better than the renderer. Instructions could save computation by doing this.