RFE: Add an option for `upsdrvctl` (CLI/`ups.conf`?) to restart dead drivers, and other refinements

[jimklimov]

In some NUT deployments, upsdrvctl is THE service manager for drivers, with nobody else (like systemd) around to restart them.

• Loosely related to idea NUT Controller (nutctld) #13

Current logic in the persistently running upsdrvctl instance that started "all" drivers is to monitor that their processes are alive (and it "was asked for explicit foregrounding"), and if something failed - stops them all and exits (assuming the external powers that be, like nut.exe wrapper on Windows, would restart it all consistently).

TODO:

• define an option to restart the failed driver, and not touch the others
• define an option to NOT restart the failed driver (at least if someone else started a copy, to avoid the tug-of-war), and not touch the others
• see if such options can be applied also to the mode where upsdrvctl starts one driver, and if it tracks driver liveliness when not remaining foregrounded itself or if we want it to in such cases
• now with upsdrvquery capability, it might also try PING/PONG sometimes to check if the driver responds
• for such status checks, and for the status CLI operation, consider using pthreads to get answers from multiple drivers more quickly (see nut-scanner code for inspiration)
• when a driver fails and upsdrvctl does exit, propagate the failed exit-code (per Investigate issue #3302 driver behavior when upsd aborts #3368 investigation, it currently returns 0 at least in Windows builds)
• certain code paths to check driver states, pass through signals, etc. are so far only implemented for non-WIN32 builds: address that