Verify that read/write PV enum_strs match

[tacaswell]

It was noted by @mrakitin that some read/write pairs have different enum_str (but the same integers), notable Acquire and Acquire_RBV in area detector (see https://github.com/areaDetector/ADCore/blob/956dbbbdcb49c6bf25608533107f6041a09470b3/ADApp/Db/NDArrayBase.template#L91-L110)

This causes problems when using set_and_wait with Signal(..., string=True) because the readback will never be equal.

We should add a check in the EpicsSignalBase that the enum strings match. Once we notice this issue we have several options:

• explode and assert this is a bug in the IOC (probably a non-starter as it is doubtful we can get AD upstream to change these names)
• demand that the user provide us a re-mapping. This is a bit brittle as now we are encoding the enum_str in the init code, but if we are using the strings else where in the code we already have the strings hard-coded so if the IOC changes names we are going to have issues anyway
• build the mapping automatically and accept either the readback or write string values for the put/set. On readback we have to pick one string to return and we should be deliberate about which one we pick.

Additionally, we probably should fallback to using the integers in set_and_wait. It is likely that we should have always been preferring the integer as the canonical value that we expect to be API stable rather than the strings. While the case within a given IOC seems solid to use integers, I'm still not sure that between IOCs the integers will be more stable than the strings (thinking particularly of the acquisition mode PVs).

[tacaswell]

also, credit to @jwlodek for pointing out exactly where in the AD databases this is defined and very useful discussion for how to handle this!

[mrakitin]

For reference, ZNAM and ONAM fields from the link above are explained well in https://www.slac.stanford.edu/grp/lcls/controls/systems/xray_transport/EPICS%20Manuals/RecordReference313.pdf.