Add UPower driver

[timn]

Enables to read UPS data from UPower. This is useful if a UPS connected to a desktop system should be exposed over the network. It can also be used to expose laptop batteries.

I have tested this with an APC Back-UPS BE1050G2 connected to a Fedora 43 host with Gnome 49.2 with UPower 1.91.0.

Example output for upsc upower-ups (minimal config with UPS auto detection):

battery.charge: 84.0
battery.runtime: 863
battery.voltage: 0.0
device.mfr: American Power Conversion
device.model: Back-UPS BE1050G2 
device.serial: <redacted>
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: upower_dbus
driver.parameter.pollinterval: 2
driver.parameter.port: /org/freedesktop/UPower/devices/ups_hiddev0
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.4
driver.version.internal: 0.1
ups.status: OL CHRG

I have also tried this on a Lenovo laptop and it works as expected (same software config). This yields the following output for upsc laptop-battery:

battery.charge: 45.0
battery.runtime: 23195
battery.voltage: 11.6
device.mfr: SMP
device.model: <redacted>
device.serial: <redacted>
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: upower_dbus
driver.parameter.pollinterval: 2
driver.parameter.port: /org/freedesktop/UPower/devices/battery_BAT0
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.4
driver.version.internal: 0.1
ups.status: OB DISCHRG

Config used:

[laptop-battery]
  driver = upower_dbus
  port = /org/freedesktop/UPower/devices/battery_BAT0
  desc = "Laptop battery"

General points

• Described the changes in the PR submission or a separate issue, e.g.
  known published or discovered protocols, applicable hardware (expected
  compatible and actually tested/developed against), limitations, etc.

• There may be multiple commits in the PR, aligned and commented with
  a functional change. Notably, coding style changes better belong in a
  separate PR, but certainly in a dedicated commit to simplify reviews
  of "real" changes in the other commits. Similarly for typo fixes in
  comments or text documents.

• Please star NUT on GitHub, this helps with sponsorships! ;)

Frequent "underwater rocks" for driver addition/update PRs

• Revised existing driver families and added a sub-driver if applicable
  (nutdrv_qx, usbhid-ups...) or added a brand new driver in the other
  case.

• Did not extend obsoleted drivers with new hardware support features
  (notably blazer and other single-device family drivers for Qx protocols,
  except the new nutdrv_qx which should cover them all).

• For updated existing device drivers, bumped the DRIVER_VERSION macro
  or its equivalent.

• For USB devices (HID or not), revised that the driver uses unique
  VID/PID combinations, or raised discussions when this is not the case
  (several vendors do use same interface chips for unrelated protocols).

• For new USB devices, built and committed the changes for the
  scripts/upower/95-upower-hid.hwdb file

• Proposed NUT data mapping is aligned with existing docs/nut-names.txt
  file. If the device exposes useful data points not listed in the file, the
  experimental.* namespace can be used as documented there, and discussion
  should be raised on the NUT Developers mailing list to standardize the new
  concept.

• Updated data/driver.list.in if applicable (new tested device info)
  I'm not sure if I need to put anything, it's now a particular hardware this supports, it rather builds on whatever UPower can support.

Frequent "underwater rocks" for general C code PRs

• Did not "blindly assume" default integer type sizes and value ranges,
  structure layout and alignment in memory, endianness (layout of bytes and
  bits in memory for multi-byte numeric types), or use of generic int where
  language or libraries dictate the use of size_t (or ssize_t sometimes).

• Progress and errors are handled with upsdebugx(), upslogx(),
  fatalx() and related methods, not with direct printf() or exit().
  Similarly, NUT helpers are used for error-checked memory allocation and
  string operations (except where customized error handling is needed,
  such as unlocking device ports, etc.)

• Coding style (including whitespace for indentations) follows precedent
  in the code of the file, and examples/guide in docs/developers.txt file.

• For newly added files, the Makefile.am recipes were updated and the
  make distcheck target passes.

General documentation updates

• Updated docs/acknowledgements.txt (for vendor-backed device support)

• Added or updated manual page information in docs/man/*.txt files
  and corresponding recipe lists in docs/man/Makefile.am for new pages

• Passed make spellcheck, updated spell-checking dictionary in the
  docs/nut.dict file if needed (did not remove any words -- the make
  rule printout in case of changes suggests how to maintain it).

Additional work may be needed after posting this PR

• Propose a PR for NUT DDL with detailed device data dumps from tests
  against real hardware (the more models, the better).

• Address NUT CI farm build failures for the PR: testing on numerous
  platforms and toolkits can expose issues not seen on just one system.

• Revise suggestions from LGTM.COM analysis about "new issues" with
  the changed codebase.