Add the diamond filter and qbpm devices

[DominicOram]

Part of DiamondLightSource/mx-bluesky#544

Instructions to reviewer on how to test:

1. Run dodal connect i03 and dodal connect i04 and confirm they pass

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

Attention: Patch coverage is 94.87179% with 2 lines in your changes missing coverage. Please review.

Project coverage is 95.03%. Comparing base (507f9ea) to head (cf26232).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/dodal/beamlines/i03.py	83.33%	1 Missing ⚠️
src/dodal/beamlines/i04.py	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #820      +/-   ##
==========================================
- Coverage   95.03%   95.03%   -0.01%     
==========================================
  Files         117      119       +2     
  Lines        4771     4810      +39     
==========================================
+ Hits         4534     4571      +37     
- Misses        237      239       +2     

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

[DominicOram]

@coretl or @callumforrester. Do we like this pattern for the different enums on each beamline or do you think better to just drop it and leave it as a str?

[coretl]

Depends, do you in code write filter.thickness.set(I03Filters.FIFTY) anywhere? If so then it's useful to check that the specified filter value exists at connect too. If not then drop to string.

[DominicOram]

I'm not sure I understand. We don't write filter.thickness.set(I03Filters.FIFTY) anywhere because there is no 50um filter on I03. The filters are different on each beamline but otherwise the hardware is the same. What I'm trying to do is allow people to write:

i03_filter = i03.filter()
i04_filter = i04.filter()

i03_filter.thickness.set(I03Filters.TWO_HUNDRED)  # All good
i03_filter.thickness.set(I04Filters.FIFTY) # Type system gives an error here, there is no 50 on i03

My concern with str was that you can then do:

i03_filter.thickness.set("200 um")  # All good
i03_filter.thickness.set("50 um") # No warning this is not valid until runtime

I wanted to make sure this pattern wasn't overly complicating things or doing something unexpected for ophyd_async though

[coretl]

The procedural case will remain compatible with this, but making the declarative approach work for this would be overkill. I'd say it makes sense for the usecase you mention.

[olliesilvester]

Looks good, and devices behaved on i03. I think what you've done with generics is good too

[olliesilvester]

Nit: It's not immediately obvious (to me) that selecting a thickness is just selecting a motor value

[DominicOram]

Added a bit more in the docstring