In the endstop testing section, add the "reverse" logic in addition to "normal" core handling.

In CoreXY/YZ/XZ steppers rotating the same direction gives X movement. Opposing directions produces Y movement.

In CoreYX/ZY/ZX this is reversed. Same = Y, Opposite = X.

----

Fixes the issue where the Y endstop was being checked when moving in the X direction, etc.

As suggested in
https://github.com/MarlinFirmware/Marlin/issues/5570#issuecomment-283059
065

- 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.

Followup to #5840

LCD call was waiting forever, causing the system to hang.

If Marlin is inside the temperature ISR, the stepper ISR is enabled. If
a stepper event is now happening Marlin will proceed with the stepper
ISR. Now, at the end of the stepper ISR, the temperatre ISR gets enabled
again. While Marlin proceed the rest of the temperature ISR, it's now
vulnerable to a second ISR call.

Hopefully fixes Marlin #5481

Addressing #5806

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

Thanks to @pavlus for this one

added conditional compilation for PWMs 1C & 3C

add Teensyduino compatibility

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

changes per review - minor formatting changes

1) remove non-printable character at the end of line 687

2) split a really long comment into two lines

3) got rid of some trailing spaces

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

Made pinsDebug_Teensyduino.h the same between this PR and PR 5668 which
is for a re-written pinsDebug.h file.

The changes were:
1) added copyright @ GNU license header
2) a blank line crept in.

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

"mea culpa, mea culpa, mea maxima culpa"

Small corrections

On last commit, some strings were ended with the incorrect character.
This fixes it.

Add missing Spanish language definitions.

If the watchdog is enabled and bootscreen + SD card checks take too long, Marlin may hang at boot time because of the reset loop. We have this happen all the time with the Anet board if no SD card is inserted.

Correction to #5629

As a showcase function for how to do waiting in the lcd menu, this function should be preserved.