feature/reactivate_go_home: an unreachable goal leads to erroneous A* result

[jjblum]

Expected behavior: if the goal in an A* calculation is unreachable, the crumb closest to the goal becomes the new goal. This repeats until the new goal is reachable.

Observed behavior: at the fishing pond, if the goal was unreachable, the result of A* seemed like the point farthest away from the goal. This could be due to a few things, I'm not sure which:

1. The calculation to find the new goal is wrong. (Seems unlikely due to the code being very similar to that used in the tablet's simulated boat that does not exhibit this bug).
2. The new goal is "reachable" in that it has neighbors, but it is not reachable from the start, and there is no check that A* terminates with the proper goal or not. (Seems unlikely, due to us being able to reproduce this issue with a similar, but not exactly the same, diamond pattern of waypoints).
3. And of course, some other unknown bug.

This will be difficult to debug directly, but could be addressed by checking if a goal is reachable by first completing A*, then checking if the final point is the goal. This only requires a refactor, but to avoid an infinite loop we also need to track the goals we have already tried, only selecting points that we have not yet tried. Also, there should be some kind of constraint, where a new goal is also only acceptable if it is at least closer to the original goal than the current position. Without this, the boat may actually end up traveling away from the original goal.

[jjblum]

Also, have the phone set the home location to the goal it is trying. That way the tablet user can observe where the boat is attempting to go.