Bots can deadlock if the MOVE pos is unreachable

[smilz0]

If we use an unreachable position in a MOVE command, the bot can get stuck trying to get there forever.
move_hipri_timeout setting is a workaround for this for the high priority moves but the other moves can take longer and we can't really set a proper timeout.
We should find a way to detect when the bot is executing a MOVE command and so detect when these deadlocks occur.
Best would be to prevent the faulty MOVE by having access to any C++ function that tells whether a pos can be really reached by the bot or not (and maybe how long it will take).

At the moment the only way to get a bot out of this deadlock condition is to use the 'lead' order and then cancel it.

[Mystik-Spiral]

@smilz0 This is not a well thought out plan, just a "brainstorm" in case it helps. What if all moves were relatively short, somewhere between 50-100 hammer units, and at the end of each move you evaluate the flow distance to the target. If you are not close enough to the target then move again. Since the distance of each move is constant, you could set a generous timeout to reach the end of the move, and if the timer expires and the bot has not reached the end of the move, then consider the bot stuck or the target unreachable.