cleanup: retire autotools, debian/, and dead platform/subtool trees - #466

PR #466 retired the autotools surface and, alongside it, deleted
docs/man/po4a.config (only used by docs/man/Makefile.am). The .po /
.pot files in docs/man/po/ and the committed *.LANG.1 manpages were
kept, but the driver that lets translators refresh them was lost.

po4a was never wired into the default build (autotools or otherwise);
the autotools tree only EXTRA_DIST'd po4a.config. Translators ran
'po4a po4a.config' out-of-band and committed the regenerated
*.LANG.1 files. This change restores that workflow without making
po4a a build dependency.

- docs/man/po4a.config: restored verbatim from the pre-PR-466 tree,
  with the xas entry dropped (xas itself was removed in #466).
- docs/man/CMakeLists.txt: find_program(po4a). When found, add an
  optional 'po4a-update' custom target that invokes
  'po4a po4a.config' from docs/man/. When po4a is absent, the
  target simply isn't generated -- no configure error, no impact
  on CI.
- docs/INSTALL: short maintainer note pointing at
  'cmake --build build --target po4a-update'.

Verified on macOS (po4a 0.74 from Homebrew): configure discovers
po4a, 'cmake --build build --target po4a-update' runs the same
'po4a po4a.config' invocation translators would run by hand, and
regenerates the *.LANG.1 / *.po / .pot files in place when their
content has drifted from the English masters.

cmake/bfd.cmake sets BFD_LIBRARY (with underscore + _LIBRARY suffix)
but src/CMakeLists.txt has been reading the bare LIBBFD at four
target_link_libraries sites (amulecmd, amuled, amule monolithic,
amulegui). LIBBFD is undefined here, so it expands to empty -- those
four target_link_libraries calls have been silently linking nothing
for years. The variable-name mismatch predates the cmake-only
migration in amule-project#466.

Why amule still linked at all on most distros: until recently libbfd
either shipped as a shared library that auto-resolved its own deps
via DT_NEEDED, or its transitive deps (libiberty, libintl) were
short enough that the linker auto-pulled them via implicit search.

Why this surfaces now (amule-project#487 follow-up): OpenSuse Tumbleweed ships
libbfd only as a static archive, with no bfd.pc, and modern ld
--as-needed defaults. The archive's transitive deps
(zstd/sframe/iberty) aren't on the link line at all because
target_link_libraries has been adding nothing. With the variable
name corrected, cmake/bfd.cmake's probe-loop output finally reaches
the link line, and the loop's job of discovering the correct
combination becomes load-bearing.

Modern cmake (4.x, the default on Tumbleweed/Arch/Homebrew/MSYS2)
prints a deprecation warning for any project declaring
cmake_minimum_required < 3.10:

    Compatibility with CMake < 3.10 will be removed from a future
    version of CMake. Update the VERSION argument <min> value.

3.10 is the floor that silences the warning, and it's also already
documented as the minimum in docs/INSTALL (rewritten in amule-project#466), so
this just closes the gap between the docs and the actual policy.

Use the modern <min>...<max> form so cmake enables policies up to
3.31 (more predictable behaviour on recent toolchains) without
raising the floor for distro packagers on older systems --
3.10 was released Nov 2017 and is available everywhere.

Two files affected: the root CMakeLists.txt, and the standalone
abstracts/CMakeLists.txt sub-script (run via cmake -P, hence its
own cmake_minimum_required).

cmake/bfd.cmake sets BFD_LIBRARY (with underscore + _LIBRARY suffix)
but src/CMakeLists.txt has been reading the bare ${LIBBFD} at four
target_link_libraries sites (amulecmd, amuled, amule monolithic,
amulegui). ${LIBBFD} is undefined here, so it expands to empty --
those four target_link_libraries calls have been silently linking
nothing. The variable-name mismatch predates the cmake-only
migration in amule-project#466.

The build worked anyway on most distros because libbfd's transitive
deps were either short enough that the linker auto-pulled them via
implicit search, or libbfd was a shared library whose own DT_NEEDED
entries dragged its deps in. On OpenSuse Tumbleweed (amule-project#487 follow-up
report) libbfd ships only as a static archive without bfd.pc, so
the explicit transitive deps cmake/bfd.cmake collects must actually
reach the link line for the build to succeed.

cmake/bfd.cmake sets BFD_LIBRARY (with underscore + _LIBRARY suffix)
but src/CMakeLists.txt has been reading the bare ${LIBBFD} at four
target_link_libraries sites (amulecmd, amuled, amule monolithic,
amulegui). ${LIBBFD} is undefined here, so it expands to empty --
those four target_link_libraries calls have been silently linking
nothing. The variable-name mismatch predates the cmake-only
migration in amule-project#466.

The build worked anyway on most distros because libbfd's transitive
deps were either short enough that the linker auto-pulled them via
implicit search, or libbfd was a shared library whose own DT_NEEDED
entries dragged its deps in. On OpenSuse Tumbleweed (amule-project#487 follow-up
report) libbfd ships only as a static archive without bfd.pc, so
the explicit transitive deps cmake/bfd.cmake collects must actually
reach the link line for the build to succeed.

cmake/bfd.cmake sets BFD_LIBRARY (with underscore + _LIBRARY suffix)
but src/CMakeLists.txt has been reading the bare ${LIBBFD} at four
target_link_libraries sites (amulecmd, amuled, amule monolithic,
amulegui). ${LIBBFD} is undefined here, so it expands to empty --
those four target_link_libraries calls have been silently linking
nothing. The variable-name mismatch predates the cmake-only
migration in #466.

The build worked anyway on most distros because libbfd's transitive
deps were either short enough that the linker auto-pulled them via
implicit search, or libbfd was a shared library whose own DT_NEEDED
entries dragged its deps in. On OpenSuse Tumbleweed (#487 follow-up
report) libbfd ships only as a static archive without bfd.pc, so
the explicit transitive deps cmake/bfd.cmake collects must actually
reach the link line for the build to succeed.

Modern cmake (4.x, the default on Tumbleweed/Arch/Homebrew/MSYS2)
prints a deprecation warning for any project declaring
cmake_minimum_required < 3.10:

    Compatibility with CMake < 3.10 will be removed from a future
    version of CMake. Update the VERSION argument <min> value.

3.10 is the floor that silences the warning. It's already
documented as the minimum in docs/INSTALL (rewritten in #466), so
this just closes the gap between the docs and the actual policy.

Use the modern <min>...<max> form so cmake enables policies up to
3.31 (more predictable behaviour on recent toolchains) without
raising the floor for distro packagers on older systems --
3.10 was released Nov 2017 and is available everywhere.

Two files affected: the root CMakeLists.txt, and the standalone
abstracts/CMakeLists.txt sub-script (run via cmake -P, hence its
own cmake_minimum_required).

Depends on the previous commit's CMAKE_BINARY_DIR fix for
version.rc -- the policies enabled by <max>=3.31 stop the
silent CMAKE_CURRENT_BINARY_DIR fallback that masked the wrong
${CMAKE_SOURCE_DIR}/version.rc references.

…mule-project#466)

The Shared Files view could only show static counters (transferred,
requests, accepts, complete sources) — unlike Downloads, there was no way
to tell an actively-seeded file from an idle one. Surface per-file upload
activity over EC so clients (the REST API now, the desktop GUI later) can
add the corresponding columns.

Core (CKnownFile):
  * GetUploadDatarate() / GetTransferringClientCount() — live, summed from
    m_ClientUploadList: current upload speed and peers uploading now.
  * m_lastUploadDatetime — stamped in CFileStatistic::AddTransferred (the
    single point where sent bytes are attributed to a file), the upload-side
    analogue of the download's m_lastDateChanged.
  * m_dateShared — stamped once when a file completes (CompleteFileEnded) or
    is first hashed into the share (CKnownFileList::Append, afterHashing).
  Both persist in known.met as new FT_ tags (FT_LASTUPLOADED / FT_SHAREDSINCE);
  absent on a pre-feature known.met => 0 (unknown). Uploading never rewrites
  the shared file, so the timestamp can't ride the .met date the way downloads
  do — it needs its own tag. The unknown-tag preserve-and-rewrite path keeps
  this forward/backward compatible.

EC / dirty-marking:
  * New tags EC_TAG_KNOWNFILE_UPLOAD_SPEED / _UPLOADING_COUNT / _LAST_UPLOAD
    (live, emitted before the UPDATE early-return) and _SHARED_SINCE (full
    detail).
  * SetUploadState marks the file EC-dirty on US_UPLOADING transitions so a
    file that stops uploading but stays queued drops its speed to 0 —
    completed/shared files have no per-tick Process() sweep like downloads.

REST + SSE (amuleapi):
  * /shared list + detail gain upload_speed_bps, uploading, last_upload,
    shared_since; the SSE shared_added/shared_updated payload and EqualShared
    comparator carry them so live changes emit events.

Tests: RefresherTest decodes the new tags; curl 04 asserts the fields.
Docs: docs/api/REFERENCE.md.

…mule-project#466) (amule-project#473)

The Shared Files view could only show static counters (transferred,
requests, accepts, complete sources) — unlike Downloads, there was no way
to tell an actively-seeded file from an idle one. Surface per-file upload
activity over EC so clients (the REST API now, the desktop GUI later) can
add the corresponding columns.

Core (CKnownFile):
  * GetUploadDatarate() / GetTransferringClientCount() — live, summed from
    m_ClientUploadList: current upload speed and peers uploading now.
  * m_lastUploadDatetime — stamped in CFileStatistic::AddTransferred (the
    single point where sent bytes are attributed to a file), the upload-side
    analogue of the download's m_lastDateChanged.
  * m_dateShared — stamped once when a file completes (CompleteFileEnded) or
    is first hashed into the share (CKnownFileList::Append, afterHashing).
  Both persist in known.met as new FT_ tags (FT_LASTUPLOADED / FT_SHAREDSINCE);
  absent on a pre-feature known.met => 0 (unknown). Uploading never rewrites
  the shared file, so the timestamp can't ride the .met date the way downloads
  do — it needs its own tag. The unknown-tag preserve-and-rewrite path keeps
  this forward/backward compatible.

EC / dirty-marking:
  * New tags EC_TAG_KNOWNFILE_UPLOAD_SPEED / _UPLOADING_COUNT / _LAST_UPLOAD
    (live, emitted before the UPDATE early-return) and _SHARED_SINCE (full
    detail).
  * SetUploadState marks the file EC-dirty on US_UPLOADING transitions so a
    file that stops uploading but stays queued drops its speed to 0 —
    completed/shared files have no per-tick Process() sweep like downloads.

REST + SSE (amuleapi):
  * /shared list + detail gain upload_speed_bps, uploading, last_upload,
    shared_since; the SSE shared_added/shared_updated payload and EqualShared
    comparator carry them so live changes emit events.

Tests: RefresherTest decodes the new tags; curl 04 asserts the fields.
Docs: docs/api/REFERENCE.md.

…oject#466) (amule-project#730)

The Shared Files view only had static counters, so an actively seeded file
looked the same as an idle one. Surface the four fields 5722207 added to
GET /shared (list and detail alike).

Table (shared.js):
  * New columns: "Up speed" (upload_speed_bps) and "Uploading" (uploading),
    both live off the existing SSE shared channel, plus "Last upload" and
    "Shared since" hidden by default -- the timestamps are wide and rarely
    watched, one click away in the column picker.
  * The totals line now sums the upload speed, mirroring the downloads view.

Detail panel (shared-detail.js): the same four values as rows in the
Sharing section, with tooltips. The existing queued-clients row is left
alone so "uploading" and "queued" read as two neighbouring rows.

format.js: fmtTs, until now local to download-detail.js, becomes the
exported formatTimestamp and is reused by both panels. Unknown timestamps
(0 -- never uploaded, or a known.met entry written before the feature)
render as a dash.

i18n: new keys in en.json and es.json.