Guaranteed Execution Order for Render Living Modification

[Kovak]

Supersedes #9672, addresses #9118

This PR does a few things:

1. Replace RenderLiving.Pre and Post with a single event, this accomplishing ensuring that if a pre event is called a post event is called to avoid 2 types of rendering issues:

• A case where rendering is occurring in the pre event while that even is cancelled by a lower priority handler, resulting in rendering when there should be none
• A case where drawing state such as the pose stack is manipulated in the pre event with the goal of restoring that state later in the post event, but because of cancellation by a lower priority handler only the pre logic occurred and not the post.

2. There has been API drift in the underlying Minecraft classes, the render function has a yaw argument being passed into it that we are not preserving at the time "p_115309_" has now been added to the new event as the yaw parameter

3. Guarantees that the order that post handlers are called is the exact reverse of the order the pre handlers are called. For certain types of render modification this needs to be true. Things like state modification of pose stack need this to guarantee their callers are not operating on another modders state, right now it is possible that Mod A and B could be popping each others pushes instead of unwinding the stack appropriately.

4. Reduces the number of events dispatched per entity rendering. My previous attempt at solving RenderLivingEvent Posestacks #9118 introduced a third event, increasing overhead. This solution actually reduces the overhead from 2 events to 1 while increasing the guarantees around rendering.

5. Introduces some examples that confirm that the 2 major problems are fixed, to see how the problems manifest in the current state of forge take a look at rendering examples to demonstrate current issues with pre/post events #9674

[autoforge]

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