Saves a few lines of code.

 - rename to PROBING_HEATERS_OFF
 - move heater pausing functionality into thermalManager
   - add variables, pause(), ispaused(), other functions
 - add fan pausing functionality -> PROBING_FANS_OFF
 - add probing_pause() wrapper
 - move pausing into do_homing_move() and do_probe_move() to minimize quiet time and so other probe types can benefit
 - example configs

spi.h is only needed if HEATER_0_USES_MAX6675 is defined, so making its inclusion conditional on HEATER_0_USES_MAX6675 being defined.

After wraparound, pwm_count <= pwm_mask holds, thus soft_pwm_X <= pwm_count
guarantees soft_pwm_X < pwm_mask is true, and the heater will be switched
off in the first branch.
Do not evaluate the pwm conditions a second time, this reduces the
instruction count (4 instructions per PWM) and text size (6 byte).

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>

The compiler is not able to reuse the value of pwm_count, but reloads it
on every evaluation, if is stored in a static variable, as it cannot prove
it will be unchanged. A variable with local scope may not be modified from
the outside, so its value can be reused.
Doing so reduces text size and instruction count.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>

If dithering is enabled, the remainder of the soft_pwm_X duty value at
turnoff time is added to the next cycle. If e.g. the duty is set to 9 and
SCALE is set to 2, the PWM will be active for 8 counts for 3 cycles and
12 counts on each fourth cycle, i.e. the average is 9 cycles.

This compensates the resolution loss at higher scales and allows running
fans with SOFT_PWM with significantly reduced noise.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>

A 128 step PWM has 127 intervals (0/127 ... 127/127 duty). Currently, a
PWM setting of 1/127 is active for 2/128, i.e. double the expected time,
or, in general n+1/128 instead of n/127.
Fixes issue#6003.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>

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.

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

to capture chars at UART at 250000 baud.