[2.0.x] LP1768 - fix PWMs

Followup to 13a3fb1acc

[2.0.x] General code clean/comment

Can LCD shift registers keep up with faster MCUs?

Remove pin count check for MIGHTYBOARD_REVE

Remove assert and unused code since it is implemented in pinsDebug_plus_70.h

[2.0.x] tool change bad behaviours

This will solve 2 issues on tool change.
1) when no home is done ("no_move" is set) tool change should never move X & Y because... I don't know where I am...only Z should be adjusted to avoid bed collision if other nozzle is lower than current.
Since no move no bed level matrix should be applied
2) When SWITCHING_NOZZLE is enabled and system is homed there are two movements to go to destination, but first can move Z to older position and then crash on the bed

Update pins_RuRAMPS

Add and bugfix pins

[2.0.x] Updates to Anet A8 configurations

2.0.x LPC1768 - M42 compatibility with Repetier Host

[2.0.x] Update PlatformIO lib_deps

[2.0.x] Fix Temperature::setPwmFrequency() prototype to match source

Introduced with #8446

[2.0.x] Dependency adjustments (e.g., sq macro)

2.0.x FAST_PWM_FAN updates & make LPC1768 PWM use fewer CPU cycles

include LPC1768 syntax for M42

couple more pin_t changes

consistency

change M42 to R, P format

Revert "change M42 to R, P format"

This reverts commit 01f12f579e.

[2.0] No retroactive adjustment with M851 Z

[2.0.x] Apply some formatting

If using babystep to adjust the Z probe offset, the axis will move and the mesh will be updated at the same time, causing a doubling of the Z offset over the rest of the print.

To correct for this, the current Z position would need to be modified in the opposite direction, canceling out the additional Z offset added to the mesh. This would be confusing to users, and moreover it would not be accurate without also taking the current Z fade level and current Z height into account.

It might make sense to change the mesh in the case where no babystepping is taking place, but this could be considered an undesirable side-effect of changing the `zprobe_zoffset`.

One way to remedy this would be to return to storing the mesh with `zprobe_zoffset` included, then subtracting `zprobe_zoffset` from the returned Z value. Thus, a babystep moving the Z axis up 1mm would subtract 1 from `zprobe_zoffset` while adding 1 to all mesh Z values.

Without including the `zprobe_zoffset` in the `z_values` there is no safe way to alter the mesh in conjunction with babystepping, although it's fine without it.

This is a non-intuitive change.   @oldmcg says in this post https://github.com/MarlinFirmware/Marlin/issues/7572#issuecomment-340641207 that using DELTA_PRINTABLE_RADIUS is better than DELTA_PROBABLE_RADIUS for setting the probe limits.   This is because the automatic probe code checks all locations for being reachable by the probe prior to doing the probe.

Based on #8426

2.0.x E0 auto fan fixes for LP1768