Co-Authored-By: TheLongAndOnly <thelongandonly@users.noreply.github.com>

* Clean up Temperature PID
* Improve EEPROM read/write/validate
* Group `SINGLENOZZLE` saved settings
* Group planner saved settings
* Group filament change saved settings
* Group skew saved settings
* Group `FWRETRACT` saved settings

When possible, make `active_extruder` a `constexpr` to save some PROGMEM.

- Allow planner to alter the deceleration phase of the currently executing block.
- Remove BUSY flag, as it is NON ATOMIC to set bits in the Stepper ISR and Planner at the same time.

...and recommended pulse width configuration for A4988

Always honor minimum period on stepper pulse generation, and fix timing calculations

Signed-off-by: etagle <ejtagle@hotmail.com>

The timing value should be properly set for ALL boards. The compiler will check and set maximum step rate calculations based on those values.

- Stepper bugs fixed
- Support MIXING_EXTRUDER with Linear Advance
- Miscellaneous cleanup

* 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

Co-Authored-By: ejtagle <ejtagle@hotmail.com>

Co-Authored-By: ejtagle <ejtagle@hotmail.com>

- Also implemented real endstop reading on interrupt.

Better encapsulation and considerably reduce stepper jitter

Alternative to the apparently superfluous double delay

Followup to #10656

Co-Authored-By: ejtagle <ejtagle@hotmail.com>