Improve limit checking for motor records (fixes #29)

[nariox]

Currently, before a scan executes, the sscanRecord checks the low and high limits of the positioners to make sure the scan range is within those limits. If the limit is set to 0, the limit is ignored (see here. This introduces two problems:

1. The "limit set to zero = limits disabled" usually is only meant if both limits are 0 (or unset). For example, aoRecord.c checks if DRVH > DRVL to decide on whether to enforce the limits (see here. This means that if a positioner has limits 0 to 100 (for example, a percentage of something), the sscan record will completely ignore the lower limit, and allow a scan from -100 to 100, for example. Of course, when the command to the positioner is sent, the positioner itself will refuse to go below 0, but I think the check was meant to capture exactly these cases.
2. The second problem is the one that we encounter often in our facility. Because the motor record has separate values for position depending on the application (raw, user and dial), we sometimes encounter situations where the limits were not set, but the sscan record refuses the scan. This is because when the limits are not initialized, the dial limits are set to 0, but the user limits are set to OFF (since the user values are simply the dial values shifted by OFF). Because of that, we tend to set the LLM and HLM fields to very large negative and positive values respectively (-9999 and +9999 typically), but that is just a workaround.

In this PR, I solve the issue in one way. I simply compare the low and high limits to each other. If they are equal, I ignored the limits, otherwise the limits are enforced. I would be open to modify it so that we replace the != with < like it is done in aoRecord.c, which would be more consistent with epics-base, but, at least in the case of motor records, would still not execute a scan, as the motor record still enforces the low and high limits, even if HLM < LLM (in this case, the motor refuses to move completely), so I think my approach is superior as it would still display the message as to why the scan did not execute properly. The only case where I think it might be overly restricting is if the positioner is linked to a record that ignores limits when the upper limit is smaller than the lower limit (like ao records), but I find that this case is fairly unusual (why set lower limit higher than the upper limit?*) and even then it is still less restricting than the current implementation (as it would allow us to continue to use user values on the motors, which currently don't work) and fixes the situation where one of the limits is 0, but it is not an ignorable 0 (as I described in case 1).

I am open to better alternatives, but I believe this change would be helpful in most cases I can think of.

• • I acknowledge that EPICS engineers are often fighting against the system, using arcane methods or straight up hacks to make something behave well, so I apologize to everyone who has relied on this behavior in their use-cases. Relevant xkcd