Use PVI information to fill in PVs on FastCS Eiger

[shihab-dls]

Fixes #551

This PR should create FastCS modules for Eiger and Odin, and write the Eiger in a declarative style with typed annotations. Currently annotations are limited to signals internatlly used by the device, and those accessed in the MX DAQ Eiger arming chain. These signals should now follow the expected format of PVI attributes.

Notes for reviewer:
These changes were made for FastCS Odin as well; capture signal, which reads Writing and writes to ConfigHDFWrite was split into two signals, which seems messy. Moreover, attribute names seem quite ambiguous.

[coretl]

Let's discuss this in the standup later, I'm not sure what is a top level controller in FastCS here...

[GDYendell]

This API doesn't seem very clear now that I am seeing it on the ophyd side... Maybe we can improve the names in fastcs-odin.

[shihab-dls]

Current	API	Rec
capture (read_pv)	writing	writing
capture (write_pv)	config_hdf_write	write
num_captured	frames_written	frames_written
num_to_capture	frames	frames
image_height	data_dims_0	Content Cell
image_width	data_dims_1	Content Cell
num_frames_chunks	data_chunks_0	Content Cell
num_row_chunks	data_chunks_1	Content Cell
num_col_chunks	data_chunks_2	Content Cell
data_type	data_datatype	data_datatype

Above is a table of current Odin signal names (i.e., ADOdin), and API signal names (i.e., Fast-CS Odin) that are not in agreement. Recommended names are provided (yet to be filled). config_hdf_write will need to be changed to write once this is properly introspected.

[DominicOram]

Can I suggest spinning the name changes off into a separate issue? Doing just a find and replace later won't be too much effort and it decouples getting the issue complete from fastcs changes

[coretl]

Can I suggest spinning the name changes off into a separate issue? Doing just a find and replace later won't be too much effort and it decouples getting the issue complete from fastcs changes

The name changes in ophyd-async? Unfortunately we can't do this, the name in PVI is the name of the attribute in the ophyd-async Device. This ticket is to use PVI to make the Eiger and Odin Devices, so I think we need to decide on names as part of this ticket...

It's possible to make a different ticket that keeps the old attribute names, but fills in the PVs from the new FastCS Eiger, but I'm not sure it is worth the effort to do that intermediate step unless you need to keep switching between the two IOCs, optimizing both...

Can we discuss in standup today?