Refactor Keithley 2600 driver to use ParameterWithSetpoints for fast sweep

[trlemon]

Background

The doFastSweep method relies on "old" technology from qcodes_loop, and it also returns a Qcodes dataset which may not be desirable for all applications. Instead, it would be better to use ParameterWithSetpoints and return a numpy array.

Summary of Changes

• Remove dependence on qcodes_loop
• Use ParameterWithSetpoints with additional parameters for configuration.
• Return fast sweep data as numpy array instead of qcodes dataset.
• Add functionality to perform both 1D (single channel) and 2D (two channels) buffered sweeps.

[codecov]

Codecov Report

❌ Patch coverage is 85.42714% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.80%. Comparing base (5d8e488) to head (155d6e7).
⚠️ Report is 160 commits behind head on main.

Files with missing lines	Patch %	Lines
...odes/instrument_drivers/Keithley/_Keithley_2600.py	85.42%	29 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7851      +/-   ##
==========================================
+ Coverage   59.94%   60.80%   +0.85%     
==========================================
  Files         352      333      -19     
  Lines       31933    32368     +435     
==========================================
+ Hits        19143    19680     +537     
+ Misses      12790    12688     -102     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[astafan8]

looks promising!

[astafan8]

is it ready for the final review, can it exit the draft mode? :)

[trlemon]

I replaced the "built-in" setpoint parameters with a setpoint parameter factory function to avoid a bug where parameters are not successfully registered to datasets when using e.g., do0d with repeated calls to setup_fastsweep and fastsweep in the same experiment. The issue with having a single instance of the inner/outer setpoint parameters directly on the instrument class is that ParamSpec is never updated when setup_fastsweep is called with new parameter information as e.g., LinSweep objects. Instead of manually cleaning the ParamSpec data on every call to setup_fastsweep, I thought it would be cleaner to create new parameters each time so that we aren't "silently" manipulating the state of any persistent parameters on the instrument itself. This also simplifies the code a bit.

Could I get some feedback on this approach @jenshnielsen and/or @astafan8?