refactor speed handling

Separate speed planning from gcode writing. For now, a fixed number of
layers is planned in advance. The goal is to slow down already before
the start of a very small layer. This will allow to smooth out speed
changes over multiple layers in a later commit.

Replace the list of points (of a planned path) with a list of
segments (new class GCodePathSegment). A segment stores not only the
XY position, but also the speed and extrusion width.

This will allow manipulations of the per-segment speed in a later
commit, to smooth out speed changes.

Rename forceMinimalLayerTime() --> enforceSpeedLimits(), which now
does all speed limits.
rename for consistency

rename "gCodeLayer" --> "plan"; no functional changes
smooth speed changes

This fixes the messup often seen in the last layers of objects that
don't have a flat top. Slowdown for cooling now starts long before
reaching the layer which needs it.

While this doesn't fix the underlying problem (which is that the bot
actually doesn't follow flow changes immediately), it distributes the
error over a very large area, making it practically disappear.

It's working. But code needs cleanup & parameter & some debugging.
Integer speed resolution in mm/s is somewhat spoiling the fun.
increase resolution of speed

Convert integer speed to double in places where it matters.

The speed resolution as an integer in mm/s is too coarse. You can
actually hear the integer steps. And in the gcode we have mm/min.

The alternative would be to store the speed in microns/s and work in
fixed-point, but it would be messier in the code. Concerning
performance, this commit is actually a tiny (1%) improvement.