Work around for slicers producing buggy gcode.

Followup to #5840

Hopefully fixes Marlin #5481

The target here is to update the screens of graphical and char base
displays as fast as possible, without draining the planner buffer too much.

For that measure the time it takes to draw and transfer one
(partial) screen to the display. Build a max. value from that.
Because ther can be large differences, depending on how much the display
updates are interrupted, the max value is decreased by one ms/s. This way
it can shrink again.
On the other side we keep track on how much time it takes to empty the
planner buffer.
Now we draw the next (partial) display update only then, when we do not
drain the planner buffer to much. We draw only when the time in the
buffer is two times larger than a update takes, or the buffer is empty anyway.

When we have begun to draw a screen we do not wait until the next 100ms
time slot comes. We draw the next partial screen as fast as possible, but
give the system a chance to refill the buffers a bit.

When we see, during drawing a screen, the screen contend has changed,
we stop the current draw and begin to draw the new content from the top.

`block_buffer_runtime_us` is mangled in the planner and in the stepper-ISR.
So it needs to be volatile and interrupt protected.

Instead of waiting for a single long block, compare the complete block
buffer runtime for the long_move() check.

lcd_update can take so much time that the block buffer gets drained if
there are only short segments. This leads to jerky printer movements for
example in circles and a bad print quality.

This change implements a simple check: Only if the block currently
executed is long enough, run lcd_update.
This also means the printer will not show actual values on the LCD nor
will it respond to buttons pressed. A option that keeps the menu
accessible is also available.
Aditionaly, slow down if a block would be so fast that adding a new
block to the buffer would take more time. In this case, the buffer would
drain until it's empty in worst case.

This allows M104 to pass the F and B parameters to enable autotemp as well

Advance has nothing todo with Z_AXIS, strange copy&paste error?

planner.h:
fan speed is used to set integer variables, so no need for long.
Basicaly a byte should be enough for all the fan things, as it's 0-255?

planner.cpp:
Save some float multiplications.
We could squeeze out even more by defining feedrate_percentage,
saved_feedrate_percentage and flow_percentage as float instead of int.
Everytime they are used in the time-critical planner, they are casted to
float and multiplied by 0.01. Not done jet, as they are used in LCD menu
functions I don't know well enough.

Added a rule so that LIN_ADVANCE isn't used for moves with negative E movements (de_float will be negative in this cases).
I also added a more detailed comment to make it more clear what the if statement does.

The extrusion speed was wrong due to a not high enough precision of
esteps to XY steps, therefore now the target float values are used to
calculate the ratio between XY movement and extrusion speed.
The e_speed_multiplier8 was replaced by an absolute multiplier called
abs_adv_steps_multiplier8, therefore one multiplication and bitshift can
be saved inside the stepper ISR. Due to this, also extruder_advance_k is
better suited inside the planner and not the stepper files any more.

.) Use already existing inverse_millimeters instead of /
block->millimeters.
.) Prevent overflow during acceleration calculation by checking if float
is necessary. Idea modified from Sailfish.
.) Save two uint32_t or even float multiplications by checking if
step[AXIS] has steps and if max acceleration is lower than accel. If
not, there is no need to check this axis.

We don't want to have retract/prime movements done with LIN_ADVANCE, that's also true with simultaneously executed Z-hops.

・Add forgotten '\'