Support ai/ao records with prec=0 as Signal[int]

[evalott100]

In #276, we fixed the bug that the panda intialises an analogOut with precision 0 as an int. The signal is made (correctly) with an int, however make_converter fails

ophyd-async/src/ophyd_async/epics/_backend/_p4p.py

Lines 219 to 220 in 58e1cf4

	if datatype and not issubclass(typ, datatype):
	raise TypeError(f"{pv} has type {typ.__name__} not {datatype.__name__}")

since float is not a subclass of int.

The fix in in #276 allows the signal to be made anyway. We should add the constraint that .PREC == 0.

[evalott100]

Once the following are merged we can drop the changes introduced in #276

PandABlocks/PandABlocks-ioc#112
DiamondLightSource/pythonSoftIOC#160

We've decided these kind of checks shouldn't be handled in ophyd-async - pandablocks-ioc should be using an int for the record if ophyd-async expects an int datatype.

[coretl]

This has since come up with the CA backend, so I think we need to support this anyway. I suggest we:

• Make the changes from Fix p4p converter bug #276 in the CA converter too
• Also assert get_unique({k: v["display"]["precision"] for k, v in values.items()}, "precision") == 0 in the PVA converter
• Also assert get_unique({k: v.precision for k, v in values.items()}, "precision") == 0 in the CA converter
• Add records in test_records.db and a test in test/epics/test_signals.py to check

[DominicOram]

@evalott100 are you doing this? Otherwise MX-DAQ would be happy to pick up

[evalott100]

are you doing this? Otherwise MX-DAQ would be happy to pick up

That would be much appreciated, there are a few tickets I'll be doing in this sprint before I get round to this one.