PyNUT: use command identifiers in description requests

[user01010111]

Closes: #3621

On Python 3, GetUPSCommands() formats command names parsed from LIST CMD
as bytes representations, sending requests such as GET CMDDESC dummy b'load.off'. Current upsd consequently returns "Description unavailable"
even though load.off has a description.

Decode the command identifier as ASCII for both the description request and
the response-prefix length. The returned dictionary retains its bytes keys
and values, and description errors retain the existing identifier fallback.
Add a request-sensitive regression test under tests, run it through
make check, and record the fix in NEWS.adoc.

Validation:

• The regression fails on unmodified Python 3 source and on a request-only
  fix; the complete fix passes on Python 2.6.9, 2.7.18, and 3.4 through 3.14.
• A fresh localhost upsd with dummy-ups advertises load.off. Against the
  same server, baseline returns "Description unavailable" and the patched
  client returns "Turn off the load immediately". Exact request bytes and
  separate unavailable/error controls were checked; no UPS commands ran.
• Generated-module, explicit-path install/uninstall, wheel-install and
  source-distribution-install checks passed. The existing suite passed
  12/12, plus all six new regression tests.
• make spellcheck, changed-line ASCII/whitespace checks, and normal
  make distcheck-light passed. The latter exercised the extracted archive's
  build, tests, installation, uninstallation and redistribution, using its
  standard placeholder handling for unselected manual pages.

No physical UPS hardware was available for testing. Validation covered
request-sensitive transport tests, Python runtime compatibility checks,
generated and packaged modules, build and distribution checks, and simulated
localhost integration with upsd and dummy-ups. Physical UPS models, firmware
versions, and hardware combinations were not tested.

AI assistance: OpenAI Codex with gpt-6-astra (x-high reasoning).
The human contributor remains responsible for reviewing and submitting
the change.

Relevant contribution checklist:

• Described the concrete behavior, compatibility and testing limitations.
• Disclosed AI use and model.
• Followed affected-file style; added source text is ASCII.
• Registered the new test in distribution metadata; distcheck-light passed.
• Added a NEWS entry and passed spelling checks.
• Human contributor has reviewed and accepted responsibility for the patch.
• DCO sign-off included in each contribution commit.

[jimklimov]

You are on a roll again, now that the previous PR merge train has left the station, and NUT CI farm is more available to queries :)

[github-actions]

A ZIP file with standard source tarball and another tarball with pre-built docs for commit 311e351 is temporarily available: NUT-tarballs-PR-3628.zip.

[AppVeyorBot]

✅ Build nut 2.8.5.5250-master completed (commit fe492a87e2 by @user01010111)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.5250-master.7z

[jimklimov]

Curious: this failed on just one build combo, for a fairly valid reason:

Traceback (most recent call last):
  File "../../../tests/pynut-commands-test.py", line 5, in <module>
    import unittest
ModuleNotFoundError: No module named 'unittest'
make[5]: *** [Makefile:2508: pynut-commands-test] Error 1

On the CI side, I can add the module so we would test the feature everywhere, but on the project source side - the module should be listed in build dependencies I think (setup.py.in or tox.ini? maybe with some keyword for test-not-runtime dependency?)

And perhaps the presence of the module should be checked in configure.ac and drive decisions in Makefile.am, similar to how Qt5/6 are detected, etc.

• UPDATE: This change landed into existing scripts/python/module/test_nutclient.py.in, at least in another PR with same problem, so probably the check should be in it, not the autoconf/automake recipes. Just try to import the module, and run/skip test cases based on the outcome. Or mixed, differently handled here and there.

So maybe until this is handled, I would NOT update that build agent, so we would know builds/checks no longer crash because of this.

UPDATE: I'm on it now...

[AppVeyorBot]

✅ Build nut 2.8.5.5265-master completed (commit b8eb25d79f by @jimklimov)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.5265-master.7z

[AppVeyorBot]

✅ Build nut 2.8.5.5269-master completed (commit b4aebc9ff0 by @user01010111)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.5269-master.7z