Port OrcaSlicer's Small Area Infill Flow Compensation

[TheSlashEffect]

This PR ports OrcaSlicer's existing implementation of Small Area Infill Flow Compensation to SuperSlicer.

The implementation is mostly a 1-1 port of the existing work, with some minor refactoring. The original idea comes from @Alexander-T-Moss, while the OrcaSlicer implementation comes from @mjonuschat.

OrcaSlicer PR
Alexander's GitHub page for the feature

Example of working feature in OrcaSlicer, feature disabled for one model:

A note on git:
I had to commit some crimes to get around GitHub's 1 fork per repo per user limitation, because I also have PrusaSlicer/OrcaSlicer forks I am working on. If you do not like the "dirty" merge commit, you can either A) create a branch which I can apply the changes on and then create a PR from there or B) let me know to temporarily delete my other fork and create one here. Do let me know what works for you.

Thank you in advance to the reviewers, as well as the original authors of the feature.

[TheSlashEffect]

I have decided to disable this feature for the first layer. Please see my reasoning here

[supermerill]

As I am working on a graph type, i'll integrate this directly onto it.

[supermerill]

some notes:

• PrintObject::invalidate_state_by_config_options is only useful for settings that are on PrintObject or PrintRegion. For the other types (Print, Gcode), then it's in the Print::invalidate_state_by_config_options method.
• I moved the options to printregion, and split the infill accordingly.
• I removed the spline header, as i'm reusing the spline code from prusa's ramming.
• I added a detector & importer to import orca's values.

[supermerill]

merged in 2.5 dev branch

[TheSlashEffect]

Nice! Thanks for the tips and review. Great work, chief

[TheSlashEffect]

Btw really nice job on refactoring the original code as well as everything about the UI. Thanks for your all your work, the project is awesome

[supermerill]

I may alter it a bit, currently if the curve go below 0, it replaced the negative values by 1, but I guess it's better to replace them with 0, as it's the "intended" (not useful but correct) value. (can happen if a spline is not well done).

[Tinchus2009]

I have a question about this because I tried it and did not get good results : the speed the slicer creates, many times will be different of what the firmware finally creates, is this being taken into account? how?

[supermerill]

@Tinchus2009
The slicer order the firmware to do stuff, but don't have any way to force it to do something it doesn't want.
What's the issue?

[Tinchus2009]

I would say based on the answer and my guess that is not an issue: I have tried the feature but having the same setting, the results vay a lot depending on the printing speed and in my particular case on the pressure advance value being used (reprap firmware)