[Grbl_Esp32 PR#718] cancel in-flight jog in mc_line() on jogCancel

Cancel/hold misses jog move that is in-flight in mc_line()

When a jogCancel or feedHold arrives, the planner is emptied and gcode parser state resets to current position, which is good. But a next jog command could already be in-flight at this point, waiting in mc_line() as the machine decelerates, and with target position determined based on gcode that has been dropped due to the hold/cancel.

UGS causes this easily by sending a continuing series of incremental jog commands while holding down a jog direction button. These can accumulate the target position to a large number, and since a jogCancel or feedHold during State::Jog results in going back to State::Idle, that stuck in-flight move gets added to the planner with the large target value intact. The machine then moves and hits the endstop. This is especially obvious and problematic when UGS is set to a jog feedrate much larger than the axis can support (since that in-flight move gets a much larger and easily out-of-bounds target position).

My simple fix for this is to create a global variable that tracks an in-flight command in mcline(). In protocolexecrtsuspend() I look for sys.suspend.bit.jogCancel being true, and if the in-flight command is a jog, I set a flag that mcline() will notice and not add it to the planner. I added an isjog flag to planlinedatat to track whether it’s a jog, and a return bool from mcline() to signal it dropped the command so that jogexecute() can signal back to gcexecuteline() that it was dropped and skip the updating of gcstate.position.

I did not touch the kinematic path to mc_line(), so I am not sure if those could still have issues.

This will only catch these in-flight moves if protocolexecuterealtime() is called when the move has entered mcline(). Currently that should catch all the cases of this happening, but perhaps some future scenarios or custom code could call protocolexecuterealtime() after a gcode line was parsed but before getting to mcline(). But I guess in that case it is no different than how it behaves without the fix.