Read aperture/scatterguard hardware on read

[DominicOram]

Following #769 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

Acceptance Criteria

• Hardware is read when the device is read
• The device holds no assumptions about the state of the hardware

[DiamondJoseph]

selected_aperture and radius are both going to be cached in the soft_signal state, so if you're modifying the handling of one should adjust the other too. Mea culpa.

[DominicOram]

I wonder if we should try and write a general rule in the docs of "devices should avoid holding state and instead read the state of the hardware when read"? Thoughts @callumforrester, @dperl-dls, @coretl?

[DiamondJoseph]

Would be nice if there was some utility for making a soft_signal backed by some function that may read other parts of device state

[dperl-dls]

I agree that that is a good guideline to have for people writing devices