This is a fix of a bug, which was in Slic3r forever, where raw slices
were not cached, but recalculated from classified regions, where
merging the regions did not produce the original contour reliably.
Fixes [2.3.0-beta2] Odd bad slicing related to infill (?) percentage #5407
If the Elephant foot compensation is applied to the 1st object's layer,
the uncompensated 1st object's slice is newly used for calculation
of bridges, overhans, skirt, brim, raft and supports.
Layer::slices were renamed to Layer::lslices to simplify reading
of the code, to differentiate from LayerRegion::slices.
Layer newly remembers bounding boxes of slices,
the bounding boxes are used by G-code generator & newly the support
generator.
Slices are stored as ExPolygons, not ExPolygonCollection.
The gap fill was disabled for zero infill.
Now the gap fill is enabled in between the perimeters, but disabled between
the inner-most perimeter and infill in case the infill is set to zero.
Also in case there are multiple infill regions inside a perimeter,
the mutliple infills are considered as non-zero if at least one infill
is non-zero, therefore the gap fill will be added inside the inner-most
perimeter.
Integration of the "cereal" serialization library.
Serialization / deserialization of the DynamicConfig / DynamicPrintConfig.
DynamicPrintConfig serializes ordinal identifiers instead
of the option key strings to conserve space.
they are presented in the UI.
Parallelized the slice stealing when splitting regions with modifier meshes.
Rewrote Layer::make_perimeters() to C++11 loops.
