Easy ~1.2x speedup for calculateRadius

[grinstead]

This adds an optimization to avoid calculating where you can go from a position if you have already maxed out.

Small note that if there is a positive, minimum cost to making a move then the if statement could be expanded to

if (nextCost + minMove <= radius) {

There is no formal benchmarking system in the repo, so this just used a homebrewed one. The (fairly unscientific) results were speedups ranging from 1.15x to 1.3x

This is to aid in #9

[grinstead]

I'm not aware of the way the transition+tile costs work, but if it is possible to move from one tile to the next with a cost of 0, then this code will break and incorrectly trim away that movement.

At the moment the VisionConfiguration and MoveConfiguration objects both do something like map.someCostCalc(vector) || -1, which implicitly will disallow 0 (as that will get replaced with -1) . In that case this diff works fine, but it's possible that the intended code was map.someCostCalc(vector) ?? -1...

[cpojer]

This is great, thank you for the contribution!

The cost for moving from one tile to the next is always greater than 0. -1 as a cost means it is inaccessible.