• Explanation of how the feature/change should work.
  Add a TurtleMoveEvent, and we can register that event by calling ITurtleAccess.registerMoveEvent(Function<TurtleMoveEvent>) or sth.
  The callback should be triggered just after the ITurtleAccess.teleportTo has invoked,
  and it better (but don't need to) could be canceled so we may add more fun things.

• Some rationale/use case for a feature. My general approach to designing new features is to ask yourself "what issue are we trying to solve" and then "is this the best way to solve this issue?".
  In AP, we got chunky turtle, and now I'm making a tamed and saddled turtle. Both of them require updates when turtle is moving (e.g. when turtle is moved, chunky turtle needs to unforce current chunk and forceload the next chunk. rideable saddled turtle have to update player's position as well)

Currently, I'm just invoking turtle.getPosition() and continues to check if it's match with old position, every single tick, which will waste a lot of resources I believe.

This event also was removed in 1.19 or 1.20, I believe.

which will waste a lot of resources I believe.

I don't think this is a big issue in practice. Polling is technically more work than if you did nothing, but it's still pretty cheap (remember, turtles are ticking BEs already, so you're already paying most of the cost). I haven't benchmarked this, but I'd be surprised if turtle upgrades took up more than 0.1% of tick time.

In the case of saddle turtles, assumedly you need to account for rotation (and animation of position/rotation), so this event is still not especially useful. Honestly, for that, I kinda wonder if we should just expose getVisualPosition/getVisualYaw directly.