As outlined in #2657, dstate.c sets ALARM as a common denominator status when encountering ups.alarm variables reported through the different device-/manufacturer-specific implementations within the UPS drivers. Previously a user had to either rely on audible alarms by the UPS or (in an unattended setting) periodically check the UPS status and variables manually to be informed of potentially severe UPS device alarm states/conditions.

This pull request introduces ALARM status handling in upsmon as the remaining piece of the puzzle to effectively act upon UPS device alarms as raised by the UPS drivers. This includes notifiers ALARM and NOTALARM for when the status is encountered and dissipates, respectively, allowing the user to now configure notifications and tasks e.g. through upssched.

By default upsmon will treat any encountered ALARM status as (potentially) severe enough to warrant an UPS being promoted to critical in a no-communication situation. This can, however, be unwarranted due to there being no common standard for what constitutes an alarm. In fact mundane alarm states were previously observed with UPS devices in HE/ECO mode, which could lead to unwarranted shutdown situations on minor connection hiccups. For this reason a 0|1 setting ALARMCRITICAL was introduced into upsmon.conf, for such users to be able to prevent upsmon from treating the ALARM status as overly severe when it's not.

As for the default behaviour (of considering such an UPS as volatile) erring on the side of caution seemed to be reasonable, as e.g. an alarm for some failing circuitry and the affected UPS later dropping offline should be concern enough for the UPS to be considered immediately critical and the system pre-emptively being shutdown e.g. by reduction/depletion of MINSUPPLIES.

fixes #2657