Enhance ways that upsd/upsmon can send signals to their running siblings

[jimklimov]

This PR aims to address concerns from issues like #123 and #1299 and optionally allow service daemon lifecycle without a PID file, including sending of signals for reload and other operations.

It adds two ways of addressing the original problems:

• Allow foreground-running mode to create PID file for upsd, by specifying -F argument twice (e.g. upsd -FF), so that service integrations, init-scripts, etc. that would switch to using a non-forking daemon can still manage it with a PID file
• Allow to specify -P pidnum argument on command line of upsd and upsmon to directly tell it the PID number of the process to signal, instead of reading the value from a PID file. This should play well with systemd units that can pass a $MAINPID variable and that is not ambiguous (upsd).

As part of the solution, it refactors sendsignalfn() into reusable pieces, adding sendsignalpid() and parsepid() methods.

It also addresses a cosmetic problem (reports of missing PID file during daemon start) where such file is probed to see if a previous instance of the daemon is running and so might conflict, and a missing file may be a problem or just means there is no competition. Logging should now be clearer about that, e.g.:

Feb 16 14:10:17 mirabox nut-server[24909]: fopen /var/state/ups/upsd.pid: No such file or directory
Feb 16 14:10:17 mirabox nut-server[24909]: Could not find PID file '/var/state/ups/upsd.pid' to see if previous upsd instance is already running!

Building on debug_min support from #683 this PR allows to change (comment/uncomment) the debug_min NUMBER setting in upsd.conf or upsmon.conf and systemctl reload nut-server or systemctl reload nut-monitor respectively, to tune debugging verbosity in the running service daemon (it is recommended to comment it away or set the minimum to explicit zero when done, to avoid huge journals and I/O system abuse). Note that for this run-time tuning, the debug_min value present in reloaded configuration files is applied instantly and overrides any previously set value, from file or CLI options, regardless of older logging level being higher or lower than the newly found number.

Note that this PR does not fully address questions from #123 about PID file (and "main PID" seen by systemd, for that matter) of upsmon which by default forks anyway into a privileged part that can shut down the system, and unprivileged child that is networked for monitoring etc. (the PID file remains that of the latter). It also does not address the location of this PID file (by default /var/run/upsmon.pid) questioned in #1297 since for the root-half of the daemon the concern is a moot point.