This is a regression wrt. PrusaSlicer 2.4.0-alpha1 due to the G-code
processing optimization and parallelization.
Related to GCode Viewer changes files modified date in windows #5079
WIP to G-code export parallelization through pipelining:
GCodeProcessor is called during the G-code export,
the G-code is no more reopened and re-read, but it is pipelined
from the G-code generator.
GCodeViewer no more parses G-code just to extract line end positions.
Removed start_mapping_gcode_window(), void stop_mapping_gcode_window(),
they are no more needed.
1) New environment variable SLIC3R_PP_HOST contains one of
"File", "PrusaLink", "Repetier", "SL1Host", "OctoPrint", "FlashAir", "Duet", "AstroBox" ...
2) New environment variable SLIC3R_PP_OUTPUT_NAME contains the name
of the G-code file including path (for SLIC3R_PP_HOST == "File")
or a name of the file after upload to the host (PrusaLink, Octoprint ...)
3) The post-processing script may suggest a new output file name
(likely based on SLIC3R_PP_OUTPUT_NAME) by saving it as a single line
into a new "output name" temp file. The "output name" file name is
created by suffixing the input G-code file name with ".output_name".
Please note that the G-code viewer visualizes G-code before post-processing.
Fixes Broken PostProcessing when script changes out-filename #6042
Replaced all "unsigned long long" types with uint64_t.
These "new" types better communicate their meaning and they are
guaranteed to behave the same on all platforms & compilers.
Tighter parsing of PrusaSlicer's own G-code annotations
to avoid clashes with comments inside user G-codes.
Also the GCodeReader was extended to return string_views instead
of copying a substring, and the GCodeProcessor was partially adapted
to string_views.
