As pointed out by #5044

About Configuration.h:
・Fix the PR #4899 (ABL: Enable by type. Bilinear for all.)
Remove Duplicated contents

・Fix the PR #4305 (Custom boot screen feature improvement)
Revert from "during boot" to "during bootup" in all the example
Configuration.h

・Fix the PR #4207 (Clean up, simplify and generalize the Allen-key-probe
code.)
Resolve and relocate the duplicated definitions in Z_PROBE_ALLEN_KEY
section

・Follow-up the PR #4805 (Additional documentation of Configuration.h)
Add forgotten changes to all the example Configuration.h

Adjust spacing

About Configuration_adv.h:
Add missing description of SLOWDOWN for DELTA

Adjust spacing

Also improve the documentation of this and related options, and set
EXTRUDE_MINTEMP to 170 everywhere.

・Put #define REPRAPWORLD_GRAPHICAL_LCD into all the example
configuration files
・Adjust spacing

Why double touch probing is not a good thing.

It's widely believed we can get better __probing__ results when using a double touch when probing.

Let's compare to double touch __homing__.
Or better let's begin with single touch __homing__.
We home to find out out position, so our position is unknown.
To find the endstop we have to move into the direction of the endstop.
The maximum way we have to move is a bit longer than the axis length.
When we arrive at the endstop - when it triggers, the stepper pulses are stopped immediately.
It's a sudden stop. No smooth deacceleration is possible.
Depending on the speed and the moving mass we lose steps here.
Only if we approached slow enough (below jerk speed?) we will not lose steps.

Moving a complete axis length, that slow, takes for ever.
To speed up homing, we now make the first approach faster, get a guess about our position,
back up a bit and make a second slower approach to get a exact result without losing steps.

What we do in double touch probing is the same. But the difference here is:
a. we already know where we are
b. if the first approach is to fast we will lose steps here to.
But this time there is no second approach to set the position to 0. We are measuring only.
The lost steps are permanent until we home the next time.

So if you experienced permanently rising values in M48 you now know why. (Too fast, suddenly stopped, first approach)

What can we do to improve probing?
We can use the information about our current position.
We can make a really fast, but deaccelerated, move to a place we know it is a bit before the trigger point.
And then move the rest of the way really slow.

No need for `MANUAL_HOME_POSITIONS`. Just set each one as-needed to
override the automatic behavior.

Unify run_z_probe
Add double touch for DELTAs.
Introduce Z_PROBE_SPEED_FAST and Z_PROBE_SPEED_SLOW
  defaulting to homing_feedrate_mm_m[Z_AXIS] and homing_feedrate_mm_m[Z_AXIS]/2