Future upgrade for PID

[Ashwolaa]

Hey everyone,

I have been spending a bit of time with the PID recently and I have a few ideas for improvement, some of which are already implemented on my git.
I propose to implement it for pymodaq >= 5.1 .
I am opening this discussion channel to get your own insights/advices on what should be done to improve it in a general manner.

As a start-up:

• Include a stability measurements, currently we do not know what are the relative stabilities of the measurements and also how to tune the PID to get the best out of it
  For now, I added a queue systems for each actuator/setpoint. One can decide on the length on the queue and this allows to know what is your current stability over the queue length. Essentially, it calculates the standard deviation over the queue. We could use the var instead if speed is needed but this relates more naturally to a FWHM.
  https://github.com/user-attachments/assets/42ad8317-2bd5-40fa-a458-1294a1b466df
  For now, it is being calculated without considering the setpoint but I plan to change this and to use or not use the setpoint in the calculation according to if the PID is currently running.

• The output and input plots are very much connected and should be symmetric as they are referring to the same data. All in all, refresh/queue length should be shared. The default should also allow the same zoom/panning on both which could be disabled in the settings.

• I do not like the epsilon variable in the case of the PID to tell the program if it successfully achieved its move. This does not take at all possible oscillations or other variations that will make the PID takes more time than usual to converge on one data point.
  In fact, most of this development is related to this feature that the move_done should be considered if the PID is stable enough. At the end of this PR, I propose to use this stability feature as the default option. I found in the move_utility_class.py that there exists a user_condition_to_reach_target function to implement this in an efficient manner but a redefinition of _condition_to_reach_target might be more justified in that case.

That's all for it, I'll add some updates if something else shows us.