[1.21.3] RegisterRenderStateModifiersEvent and EntityRenderState extends AttachmentHolder

[dhyces]

Closes #1638

Consider this an RFC atm.

This PR targets extensibility of EntityRenderState due to how inextensible the new render state system is. To do this, we will expand the class with AttachmentHolder to allow users to query attachment data in rendering. The attachments are copied to ensure the values are not mutated between the render state update and the user's custom rendering. The other system added on top allows for adding client-sided elements to render states, used when the data stored is not related to attachments. To accomplish this, a new event is added RegisterRenderStateModifiersEvent. The event currently has only one method, registerEntityModifier, which accepts the targeted renderer class and a modifier function, though should be extended with another method registerItemModifier in 1.21.4 for ItemStackRenderStates. The EntityRenderStateModifier accepts the entity instance and the render state, after calling extractRenderState. Users would then modify the render state by calling IEntityRenderState#setRenderData with a statically initialized ContextKey and the data they wish to store. Every modifier that applies to the renderer is run, including modifiers that target superclasses. These collections are cached to be as efficient as possible.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

[Technici4n]

I think that having:

• The attachment holder (which is weird if it's mutable I think).
• The ad-hoc key system to add extensions.
• The extension/merger system.
  is 3 ways of achieving essentially the same thing. That's too much. I think there should only be one way.

Also, are there thread-safety or similar issues that would force us to make the data immutable? Or is it fine to directly reference the entity or something that it contains?

[dhyces]

I think that having:

• The attachment holder (which is weird if it's mutable I think).
• The ad-hoc key system to add extensions.
• The extension/merger system.
  is 3 ways of achieving essentially the same thing. That's too much. I think there should only be one way.

Also, are there thread-safety or similar issues that would force us to make the data immutable? Or is it fine to directly reference the entity or something that it contains?

I mentioned in the description that the key system and extension system were two different examples for how it could work, only one would be implemented. I somewhat agree that the attachments would be enough (and yes, while it's mutable, it's a copy and wouldn't affect the client entity), though there may be some aspects that simply would be better off not using attachments and should use something else to extend the RenderState. Tslat mentioned in neocord that generic extension outside of attachments would be necessary.

[Technici4n]

An idea might be to use a context map 🤔

[neoforged-automation]

@dhyces, this pull request has conflicts, please resolve them for this PR to move forward.