Refactor infill rotation

[SoftFever]

Description

This PR refactors the infill rotation system

1. Refactored the UX logic for handling infill rotations. Now, "Sparse infill direction" and "Sparse infill rotation template" are mutually exclusive. When "Sparse infill rotation template" is used(non empty), both "Sparse infill direction" and the automatic 90-degree rotation logic (e.g., Line) are disabled.

2. Removed solid infill insertion-related code from the sparse infill rotation template, as it does not logically belong there. A new option should be created for this in the future. Additionally, the current implementation has issues because solid infill should not be inserted directly above sparse infill.
   It will be addressed in another PR

3. Refactored the overall infill rotation logic to improve code quality and clarity.

This also fixes bug #10469.

Screenshots/Recordings/Graphs

Tests

Are you sure you want to enable this option?

[kisslorand]

Thank you very much for this fix. I took it for a spin and I have several observations.
It indeed fixes #10469 but the GUI settings are not what expected.

"Solid infill direction" is greyed out for whichever "Internal solid infill pattern" is selected and its value is not taken into account for the the "Solid infill rotation template". I couldn't find any "Internal solid infill pattern" for which the "Solid infill direction" was taken into account.
Another observation is that there's absolutely no difference between "Aligned rectilinear" and "Rectilinear" as "Internal solid infill pattern". Whichever is selected the result is the same.

Side note:
"Rectilinear", "Aligned rectilinear" and "Rectilinear interlaced" have been a source for confusion, they are not consistent in their meaning across the menus, where they are used. "Rectilinear" for support interface pattern produces the same pattern as "Aligned rectilinear" for top surface pattern, "Rectilinear" for top surface pattern produces the same pattern as "Rectilinear interlaced" for support interface pattern. Can you unify them? Maybe ditch the versions of "Rectilinear" and just simply add rotation template... no more confusion.

[SoftFever]

Thank you very much for this fix. I took it for a spin and I have several observations. It indeed fixes #10469 but the GUI settings are not what expected.

"Solid infill direction" is greyed out for whichever "Internal solid infill pattern" is selected and its value is not taken into account for the the "Solid infill rotation template". I couldn't find any "Internal solid infill pattern" for which the "Solid infill direction" was taken into account. Another observation is that there's absolutely no difference between "Aligned rectilinear" and "Rectilinear" as "Internal solid infill pattern". Whichever is selected the result is the same.

Thank you for testing it.
it should be fixed now

[kisslorand]

Tested, working as expected. Thank you!
 Maybe it worth mentioning somewhere that: "Some patterns have internal rotation pattern implemented (ex. Rectilinear) working in conjunction with the user given static rotation infill direction. That internal rotation pattern and any static direction defined is overridden if a user specified rotation template is present." - at least this is how I understood what this PR brings

[pi-squared-studio]

@SoftFever
Great! I am glad to see that the topic has not died down, continues to develop and finds a response from ordinary users.
I also want to remind you that I have completed my big topic. #10314 and there I included a small critical addition on the metalanguage of rotation. It concerns the input of fractional values, and I have corrected the description accordingly.

@kisslorand

"Rectilinear", "Aligned rectilinear" and "Rectilinear interlaced" have been a source for confusion,

This is most likely about compatibility with older configurations. The Rectilinear fill still comes from the all-original Slic3r and is calculated in a special, unique way that requires an internal rotation algorithm. It cannot be excluded just like that without possible errors.

[pi-squared-studio]

2. Removed solid infill insertion-related code from the sparse infill rotation template

Yes, it makes sense. This does not carry any semantic load when it comes to "open" infills, for example, for translucent plastics. But for "programmable" infills, can assume the presence of an ordinary bridge that will run from wall to wall. Then users will be able to strengthen the models laterally, for example, every 10% of the height.

[pi-squared-studio]

Old links detected. Need "strength_settings_infill_rotation_template_metalanguage"

Sorry to show it like this, it's just that this PR has not yet been merged with main