Move self._animate out of move_entity

[JBecquer]

from PR #39:

Not a huge fan of having this "buried" in the move_entity function, but it needs to take in frame_movement somehow...

Maybe we could move this to the update function and then just call direction_to_target() again to get the vector? We would be running direction_to_target() twice per entity but would make the code a bit cleaner, I think.

[JBecquer]

PhysicsEntity update() uses movement, which from the hero is going to be a len==4 array. Moving _animate to update() won't work in this case because _animate needs an input of frame_movement which is len==2.

Basically, if we do want to move this we will need to take in to account the differences between hero and physicsentities.

[JBecquer]

This created issues on PR #71 , because the function move_to_target() eventually calls move_entity() which calls animate(). I tried to pause the movement of the spheroid by pausing the move_to_target() function, but this resulted in the animation pausing as well, which felt like a bug. This happened because the animate() function is "buried" inside these movement functions.

We need find a way to separate these to avoid confusing logic situations like the one described above.

---

Note, the solution for this became the following, which again just feels a little wrong. Pausing move_to_target() but still calling move_entity() even though that technically stops movement...

  if not self.pause_mvmt:

      super().move_to_target(target_pos=self.target_posit,

                             movement=movement,

                             scaler=.7,

                             move_dir=None)

  else:

      # move_entity with default 0 movement called, to pause movement while still updating animations

      super().move_entity()

Note note, I tried calling move_to_target() with target_pos = current position of the entity, but this resulting in a weird "buzzing" of the image when it was stopped. I also tried setting the movement = (0, 0) here but that did nothing, probably because the movement defined in move_to_target() will eventually be replaced by the calculated movement somewhere else.