WIP on moving sprites to the path correctly

[darzu]

Test project: https://makecode.com/_eCTHYFMLqg3Y

future TODO: transition sprite gently to middle of first tile

this PR TODO:

• [x] Try dikjstra's instead of distance-squared for getting onto nearest path
• [x] Create stress test

Current state:

Notice how they move to the path but don't follow it once they get there

[darzu]

Working pretty well!

[darzu]

Looks good, other comment can be fixed in a separate change if you want / is a bit of an edge case

I'm going to try your approach and run a stress test and see how much we can handle

[darzu]

Updated to use Dijkstra's to get to the path:

[darzu]

Hmm there's definitely some buggy behavior going on that I need to look into:

[darzu]

Yeah, it's definitely buggy with the removing and add even with the run-in-parallel code. I'll see what I can do

[darzu]

Some adversarial routing with probably a couple hundred sprites active:

Not too shabby! A couple seconds delay on my macbook pro. Unsure how this will perform on hardware.

[darzu]

Alright I made a pass over the path following logic and made a few minor improvements:

1. Instead of teleporting to the start of the path, I just set the velocity to face that title
2. Instead of keeping a seperate "to remove" list, I enumerate the sprites backwards so that I can do "removeAt" and "push" without affecting the worklist. This makes it so that I don't need the "run in parallel" code anymore and also fixed some bugs around sprites not resuming pathing properly if there are lots of path switches.
3. I use vector math instead of atan2 + cos + sin to set direction; sqrt is much faster than trig functions generally
4. Fixed a bug where we weren't setting the a new "on end" callback correctly

I think things basically work well now:

There are some weird interactions when sprites are place inside of walls (e.g. placing a tower on them). Sprites don't get back onto the path. But I'm not sure the path following logic can do too much about that.