Generalize Corfunc Slider

[jellybean2004]

Description

This refactors the Corfunc slider into a reusable component so it can be shared by Invariant, making the slider generic and reusable for components that need different constraint semantics (e.g., Invariant needs to permit extrapolation beyond the raw data).

• Takes CorfuncSlider.py out of src/sas/qtgui/Perspectives/Corfunc
• Renames to ExtrapolationSlider.py and places in src/sas/qtgui/Utilities
• Moves utility classes from src/sas/sascalc/corfunc/calculation_data.py to src/sas/sascalc/util.py
• Updates all imports/usages to match the new locations and names

Behavioural change (boundaries)

Introduces two distinct boundary pairs used by different callers:

• Data range — the actual start/end of data points (existing boundary used by Corfunc).
• Extrapolation range — a broader fixed range used by Invariant (10e-5 … 10).

Usage differences:

Corfunc: uses Data range only (no functional change except location/imports).
Invariant: uses both:

• Low-Q end and High-Q start are constrained within the Data range.
• High-Q end extends into the Extrapolation range.

Fixes #3824

How Has This Been Tested?

Ran the program and tested the slider functionality in both perspectives.

Review Checklist:

[if using the editor, use [x] in place of [ ] to check a box]

Documentation (check at least one)

• There is nothing that needs documenting
• Documentation changes are in this PR
• There is an issue open for the documentation (link?)

Installers

• There is a chance this will affect the installers, if so
  • Windows installer (GH artifact) has been tested (installed and worked)
  • MacOSX installer (GH artifact) has been tested (installed and worked)
  • Wheels installer (GH artifact) has been tested (installed and worked)

Licensing (untick if necessary)

• The introduced changes comply with SasView license (BSD 3-Clause)

[DrPaulSharp]

Some points on appearance to address here. Once you've sorted out the colours, have a look at the slider before data is sent to the perspective, does it look right at that point?

Also, I've found a bug, if the slider is invalid in the invariant perspective in such a way that the boxes go red but the dialog is not shown (e.g., low q end is greater than high q start), then it is still possible to run a calculation with the invalid input. See screenshot:

[DrPaulSharp]

What happens if individual parameters other than self._max are set to None?

[jellybean2004]

I do not think that is a possibility. Only ex_q_min and ex_q_max can be None and only in the case of Corfunc. The other parameters are always set to a certain value.

Is that not the case?

[DrPaulSharp]

Yep, I've got it now I've had a look at the utils. Given you have a set expectation of what the parameters should be I'll gently nudge you in the direction of my favourite python library pydantic . . .
If we have more dataclasses like these it may be worth us introducing it here down the line.

[jellybean2004]

@DrPaulSharp thank you for your review.

I have updated the slider input validation logic in both Invariant and Corfunc to account for edge cases and disable the buttons if the values are invalid. I have also rewritten the logic in Corfunc to match that of Invariant. So, instead of popping a dialog box on press, the button is just greyed out. What do you think of this?

I will also look into Pydantic a bit more.

[DrPaulSharp]

Hopefully we're nearly there, I've found one more problem. When you load data into Corfunc, unchecking the "Fit Guinier" checkbox (and other checkboxes) disables the "Go" button. However, when the checkbox is re-checked, the button is not re-enabled.