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

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

Also simplify logic on all ARM-based interrupts. Now, it is REQUIRED to properly configure interrupt priority. USART should have highest priority, followed by Stepper, and then all others.

Enable 6th-order jerk-controlled motion planning in real-time.
Only for 32bit MCUs. (AVR simply does not have enough processing power for this!)

* Automatically reset stepper timeout in manage_inactivity

Any code that adds moves to the planner can skip resetting the stepper timeout. We can let `idle` / `manage_inactivity` reset the timer whenever it detects any moves in the planner.

* blocks_queued => has_blocks_queued

- `M666` is static, not inline
- Disambiguate some stepper macros

A capital idea from https://github.com/MarlinFirmware/Marlin/pull/9914#issuecomment-371614153

Followup to #9985