Moving average quaternions flip unintentionally

[ButterscotchV]

Moved from Discord: https://discord.com/channels/817184208525983775/948579740225261598/1333736861293744138

It seems like in QuaternionMovingAverage, there's addQuaternion which happens every dataTick and then update that happens every tick, I think the desync between dataTick and tick could be causing the tracker's rotation to be inverted when big server slowdowns happen.

I'm not exactly sure that's what's happening as I can't actually recreate it myself, but I think that's a fairly plausible explanation, as the tracker's rotation only needs to change by 90 degrees in that time, which if you're stuttering badly, I could see easily happen when turning around or something. This is worsened when using smoothing or prediction, as it also adds the latency of smoothing or latency/overshoot from prediction into the 90 degree change required.

I propose that the tracker's positive/negative rotation should be tracked in dataTick, then non-tracked interpolation can be done from that on tick for smoothing/prediction. The range for swapping positive/negative could also be reduced, making it something more like a 100-135 degree angle required so that it's less likely to happen. Ideally we'd just track this on the tracker itself, but if we really need to track it in the server, then so-be-it.

We could probably also try to be smart and assume 180 degree bends in the body probably aren't quite right and correct for it, but idk about that.

This is still a big issue, we now have a minor workaround for waist interpolation, so we can handle inversion for it (though it still happens), but this code is now what's preventing foot plant and toe snap from functioning properly. This may also be related to full/yaw reset? Will need to be looked into further.

[ButterscotchV]

I've fixed the desync issue in #1351, it turns out there's a lot more of a problem to this. We may need to track the polarity after tracker resets have been applied rather than on the raw rotation.

Marked this as low priority, since this doesn't actually break current functionality.