Motor: consider auto-correct of motor - encoder difference

[FreddieAkeroyd]

We are currently able to automatically correct any motor - encoder drift, but this is not enabled by default. If this difference gets too large it can lead to issues such as #5219 It is however useful to know what an accumulated drift has been.

Acceptance criteria

• Discussion with interested parties, specifically motion control group.
• add a new accumulated drift PV (autosaved and archived) that will record total drift, this would be zeroed only on a home maybe? the "current drift" pvs would remain as is.
• consider axes that should have auto-correction applied

[DominicOram]

Could do in conjunction with https://github.com/ISISComputingGroup/IBEX/issues/5201

[FreddieAkeroyd]

We should consult with our customers (motion group, instrument scientists) as to what they would wish doing. We should lay out the scenarios, possible actions and any consequences. Once case to consider might be encoder failure, the motor may continue to move but would be reported "stalled" as the encoder would not move. If the motor position was corrected back to the (broken) encoder position, it would definitely be incorrect if the system was later put into open loop (it might be incorrect anyway as without an encoder you don't know for sure it actually moved to where you asked) and if the axis could not be homed potentially even more lost beam time. I am also aware that we do not necessarily want to alarm a user with "out of position" warnings, or lose beam time during the night when nobody is around if there is something that could be done. So we would likely need to do auto correction on a case by case basis and additionally only enable it on axes that can be "homed". Wording and form of warnings would need to be discussed with customers - doing a home to resync may not be convenient, so we may need to provide a "resync motor and encoder" button on the advanced motor screen.