Adjust when the EntityTrackingEvents are fired.

[Octol1ttle]

The current implementation of the two events in EntityTrackingEvents isn't particularly useful. Both events fire at a bad timing - the client no longer knows of the entity by the time the callback is triggered. Attachment Sync had to implement its own mixin to work around this.

This PR changes so that START_TRACKING fires after the initial entity packets have been sent to the client and STOP_TRACKING fires before the destroy packets are sent.

These changes result in mods being able to have infinitely more functionality associated with these events, because the client is aware of the entity's existence in both events (e.g. StartTracking can finally be used in Attachment Sync)

Supersedes #3696. I don't think having extra events is the solution to this problem.

[Syst3ms]

Possibly a breaking change behavior-wise, but I would be surprised if any mods actually relied on the old behavior's quirkiness. Worth looking out for, though.

[Linguardium]

in my opinion, to prevent a breaking change, a new event could be added in the desired places. maybe add a before and after event for both, deprecate the existing event and call it from the before event. that way its clear when the events are called, as well

[Octol1ttle]

This "breaking change"... is it in the room with us right now?

I've yet to see any real-world case where existing users of these events would encounter non-trivial problems with this PR's implementation. When I used GitHub's global search to find usages of these events, a significant majority of them was S2C communication, which only benefits from this PR

As mentioned in the PR description, I don't want "before" and "after" events because half of them will only be used in <1% of consumer code.

[modmuss50]

Im happy with this, it makes much more sense.