Since #3068, replacement patterns can take the form of {setting_nr, extruder_nr}. This form was not being recognised when determining if CuraEngine should prepend its own preheat sequence.
The replacement pattern is (optionally) extended with an extruder_nr: {setting_key,extruder_nr}. The extruder_nr can either be a number (-1 for the global stack, 0 or higher for an extruder), or a setting keyword such as support_extruder_nr etc.
Contributes to #1296
CURA-4705
A SceneNode and its decorators can be deepcopied. However, the data in
some decorators will only be updated when a per-object settings stack
triggers a property changed event. That event cannot copied. So, it can
happen that a deepcopied SceneNode has inconsistent data in some of its
decorators than what's in the per-object settings stack.
The message was generating a list of settings that had an error state by going through all extruder stacks and the global stack, but didn't bother to check the per-object stacks. I could've added it to the regular message but then the user would be confused because he can't find any errors either. So instead I opted to specify that it happened in per-model settings. It's not perfect, but should narrow down the user's search considerably.
Fixes#2427.
Moved some common code into a subroutine. Also replaced the start and end g-code directly in the settings list instead of checking for the key at each iteration of the loop.
Objects that aren't printed, such as infill meshes, can simply be sent to the slicer regardless of whether they are inside or outside the build volume, because they don't generate g-code in their own volume. This way you can have a model that is partially outside the build volume that still does its anti-overhang task or whatever.
Contributes to issue CURA-3951.
When there is 1 extruder, the frontend stores all settings in the global stack. Sending an extruder stack confuses CuraEngine into using the values of the extruder stack, which results in defaults being used.
