Refactor ApertureScatterguard to return individual signals

[DiamondJoseph]

Fixes an issue discovered as part of #679, bluesky/ophyd-async#550 (comment) : SoftConverter is no longer exported from ophyd_async as of 0.5.0, and @coretl @danielballan think that bluesky/ophyd-async#310 should not include being able to pass arbitrary objects, only those that are tableable [tabulable? tabulatable?]. This change therefore adjusts how the ApertureScatterguard returns its signals to be nested under its child devices but as invidual signals.

Instructions to reviewer on how to test:

1. Ensure that the ApertureScatterguard can still connect and be read
2. The documents for the signals contained inside the device should only use primitive float types.

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}

[DiamondJoseph]

This then becomes a requirement for #679

[DiamondJoseph]

Making a Hyperion patchset now

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.52%. Comparing base (8702cc8) to head (a2f1e77).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #769      +/-   ##
==========================================
- Coverage   94.52%   94.52%   -0.01%     
==========================================
  Files         115      115              
  Lines        4621     4599      -22     
==========================================
- Hits         4368     4347      -21     
+ Misses        253      252       -1     

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

[dperl-dls]

This is great, thanks

[dperl-dls]

❤️

[DominicOram]

A side effect of this is that we're no longer reading the state of the hardware whenever we read selected_aperture. This means that the device itself is holding on to the state of the beamline based on what state it last moved to. This means that the state could be wrong if:

• The device has just been initialised
• The hardware has been moved via EPICS/manually
• There was a failure in moving the device

Was this a deliberate design decision @DiamondJoseph?

I think this is a definite issue, made #782. Feel free to comment on there if you disagree.