When endstops/probe are enabled `ENDSTOP_NOISE_THRESHOLD` calls to `update` are required to properly re-sync endstops/probe status.

* Apply #pragma once in headers
* Adjust some thermistors formatting
* Misc cleanup and formatting

Make the endstop report method track endstop changes on its own.

* Misc fixes and improvements

- Get rid of most critical sections on the Serial port drivers for AVR and DUE. Proper usage of FIFOs should allow interrupts to stay enabled without harm to queuing and dequeuing.
  Also, with 8-bit indices (for AVR) and up to 32-bit indices (for ARM), there is no need to protect reads and writes to those indices.
- Simplify the XON/XOFF logic quite a bit. Much cleaner now (both for AVR and ARM)
- Prevent a race condition (edge case) that could happen when estimating the proper value for the stepper timer (by reading it) and writing the calculated value for the time to the next ISR by disabling interrupts in those critical and small sections of the code - The problem could lead to lost steps.
- Fix dual endstops not properly homing bug (maybe).

* Set position immediately when possible

- Also implemented real endstop reading on interrupt.

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

`FORCE_INLINE` seems to have no effect with standard optimization.