Implement concrete analyser classes for beamlines to remove generics

[oliwenmandiamond]

Remove the generics from the analysers by implementing analyser models for each analyser type. This will also allow for beamline specific behaviour to be later implemented on an analyser.

Instructions to reviewer on how to test:

1. Do thing x
2. Confirm thing y happens

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.09%. Comparing base (c340ca5) to head (7db944a).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1821   +/-   ##
=======================================
  Coverage   99.09%   99.09%           
=======================================
  Files         303      306    +3     
  Lines       11446    11486   +40     
=======================================
+ Hits        11342    11382   +40     
  Misses        104      104           

☔ 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.

[Villtord]

Nice! Surprisingly it is less code that I expected for moving away from more generics classes.

[Villtord]

do you want it maybe to be more of internal object self._driver?

[oliwenmandiamond]

I think having access to the driver is okay. Beamline scientist can then still read and move individual signals in their scripts e.g i09 example, by doing ew4000.driver.lens_mode instead of using having to expose this as another object.

[Villtord]

but without this line it would be ew4000.controller.driver.lens_mode - not a big difference, ideally it should be probably just ew4000.lens_mode

[oliwenmandiamond]

controller is saved as self._controller so is private.

We can shorten it and have it saved drv so is ew4000.drv.lens_mode

[Villtord]

what happens when you later call super().init(...) i? will it then overwrite this driver object with self.driver = controller.driver from ElectronAnalyserDetector class?

[oliwenmandiamond]

The scope of driver in this class is only inside __init__ as it isn't saved to self and is passed directly to the parent class. Inside the parent class it will save it as self.driver so is accessible via analyser.driver and participates with naming and connect. So there is no overriding or classing.

[Villtord]

you could then just create it without naming directly in B07ElectronAnalyserController

[oliwenmandiamond]

Do you mean like this?

       controller = B07ElectronAnalyserController(
            B07SpecsAnalyserDriverIO(prefix), 
            energy_source,
            shutter
        )
        super().__init__(controller, name)

Yes I could do it like this, but think it is much cleaner to do the above (and less lines?)