Extend driver data dump (requested over socket protocol without `upsd`) with printout by caller

[jimklimov]

Recent work for #1903 (and issues/PRs stemming from it like #1907) added ability to request data dumps from a running driver for troubleshooting/debug. These dumps (as made now) havven via signals and go to stdout of that driver so probably into some log, systemd-journal, or lost if console is detached. Discussion suggested that we may want another driver instance to start, request the data from the running driver, and quit, without disrupting its normal monitoring work. After work in #1922 adding an upsdrvquery mini-client, this could be achieved easily.

[jimklimov]

@aquette : BTW, would something like this be useful for SmartNUT initiative? In any case, note that quite a few changes happened in the driver-server protocol (also driver-driver signaling at times, e.g. to reload/kill a sibling) between 2.8.0 and 2.8.1 - this may impact (hopefully help) your new designs in the area :)