The tool_change function saves the current_position to the destination
array soon after starting.  Later in the switching extruder section, the
destination array is modified when moving the Z axis up & down.  A later
section of tool_change moves the head back to the “original location”
using the destination array.  This later section assumes that the
destination array hasn’t been modified.

The fix is to save the destination Z position and then restore it after
the Z movements have completed.

Going back to using the current_position array for the switching
extruder Z axis moves (and  leaving the destination array untouched)
doesn’t fix the problem.

This bug was introduced by the “Make tool_change kinematic compatible”
commit # 847429eff4 which was merged on 10
Oct 2016 as part of PR 4982.

This bug was discovered in Issue 5966.

Pre-compute the combined position shift and home offset to save a
single float fetch-and-add per conversion. Great for delta/scara and
bed leveling.

Remove unnecessary line break from M48 V1 output.

Work around for slicers producing buggy gcode.

- Add configuration support for zigzags in either the X or Y axis, for
wipe pads significantly longer in one dimension.
- Add configuration for default number of zig-zag triangles, vs. a
magic number in `Marlin_main.cpp`.
- Update description of auto nozzle wiping to match functionality

Also add a hotend indicator to the heating message displayed on the lcd status line.

Addressing #5625

To guarantee that the 5mS pulse from a BLTouch is recognized you need to
have the endstops.update() routine run twice in that 5mS period.

At 200 steps per mm, my system has problems  below a feedrate of 120 mm
per minute.

Two things were done to guarantee the two updates within 5mS:
1) In interrupt mode, a check was added to the temperature ISR.  If the
endstop interrupt flag/counter is active then it'll kick off the endstop
update routine every 1mS until the flag/counter is zero.  This
flag/counter is decremented by the temperature ISR AND by the stepper
ISR.

2) In poling mode, code was added to the stepper ISR that will make sure
the ISR runs about every 1.5mS.  The "extra" ISR runs only check the
endstops.  This was done by grabbing the intended ISR delay and, if it's
over 2.0mS, splitting the intended delay into multiple smaller delays.
The first delay can be up to 2.0mS, the next ones 1.5mS (as needed) and
the last no less than 0.5mS.

=========================================

BLTouch error state recovery

If BLTouch already active when deploying the probe then try to reset it
& clear the probe.

If that doesn't fix it then declare an error.

Also added BLTouch init routine to startup section

Store N in the right variable.
This is too rarely used.

"mea culpa, mea culpa, mea maxima culpa"