[1.1.x] Improve sync of planner / stepper position, asynchronous G92

[thinkyhead]

In relation to #10611…

Background: Currently if we set the planner position directly, as with G92, we have to call stepper.synchronize so the stepper positions aren't updated in the middle of stepping, which would lead to the stepper counts being out of phase. The rationale for this is that setting the stepper positions in the middle of a move breaks forward kinematics, which need to be relied upon to accurately get the high-level position from the steppers.

• Problem 1: It's still possible for steps to get out of sync with the planner, in spite of best intentions. The stepper method to set the position does turn off the stepper interrupt, but this comes too late. It's remotely possible that the stepper ISR could start processing the next block in-between the stepper.synchronize at the start of G92 and the call to stepper.set_position_mm at the end of G92.

• Problem 2: Many slicers insert G92 E0 at the start of each layer, presumably to keep the G-code smaller and to avoid the E coordinate growing too large to fit in a float (or to maintain its precision).

  (This concern is overblown. With 500 Esteps/mm, you could go through ~4.3km of filament before the stepper E value will grow too large to fit into an int32_t.)

  The bigger problem is that G92 E also invokes stepper.synchronize, and this has been found to produce seams in the print due to the extra pause between layers. Some slicers may even use G92 E after every meter of filament, giving even more strange pauses. To make all axes recoverable, including E, the synchronize is necessary even for G92 E. The most simple solution is to be loose about E and only synchronize for XYZ, but there may be good reason that the synchronize was added for E.

If G92 didn't require a call to stepper.synchronize then both problems would be solved.

Solution: Instead of requiring the stepper.count_position to be set at the same time as planner.position, it makes more sense to let the stepper ISR do this at the best moment. This PR accomplishes this by adding a block flag that instructs the ISR to copy the block steps values directly to the step_count then throw away the block. This allows G92 to work without needing to call stepper.synchronize.

---

Also:

• Audit code that calls stepper.synchronize and, where possible, either move the call to a later point to use up some cycles in code that needs to run anyway, or remove the call if it is superfluous.
• Fix fwretract.retract (finally?) by taking advantage of this updated method to set the planner position.

---

Counterpart to #10614