cmake: link libatomic on 32-bit targets where std::atomic<int64_t> needs it - #648

PR #648's cmake/atomic.cmake uses check_cxx_source_compiles to decide
whether linking libatomic is required for std::atomic<int64_t>. The
probe runs a tiny main() that stores / loads / fetch_adds /
compare_exchanges a std::atomic<int64_t>, then links it. On 32-bit
targets the compiler can inline the entire lock-free expansion of
those operations end-to-end -- no __atomic_*_8 library-call symbols
are emitted, the link succeeds, and the probe reports 'native 64-bit
atomics work, no -latomic needed'.

The real codebase's atomics live in CDownloadBandwidthThrottler
member functions called across translation-unit boundaries. GCC
can't inline those, emits __atomic_compare_exchange_8 /
__atomic_load_8 / __atomic_store_8 / __atomic_fetch_add_8 references,
and the link fails with the original Undefined Symbols errors the
probe was supposed to detect. Reported by @barracuda156 on PPC32
MacPorts -- amule_HAVE_NATIVE_ATOMIC64 = Success at configure, link
failure at build.

The probe heuristic is fundamentally fragile (any in-TU inlining
hides the library-call references) so drop it. 32-bit CPUs lack a
hardware 8-byte CAS -- the answer is always 'libatomic required'.
Just look up the library with find_library(NAMES atomic) and link
it; 64-bit targets stay a no-op.

Move the new logic to the top of the root CMakeLists.txt where the
include statement used to be. cmake/atomic.cmake is deleted. The
hard-fail message preserves the per-distro install hint the
previous FATAL_ERROR carried.

Closes #643 properly.

…es (amule-project#648)

Adds drag-to-resize columns (persisted per-table in localStorage) and a Reset-columns action to every data table, implemented once in the shared table.js (useTablePrefs + VirtualTable + ColumnPicker) and threaded through the Downloads, Shared, Search, Servers and Clients views. Resize uses Pointer Events with setPointerCapture (mouse + touch), commits only on an actual width change, and routes the live drag width through component state so an SSE-driven re-render mid-drag can't stomp it. Completes amule-project#361.

* feat(search): persist search history across restarts (amule-project#641)

The search field was a plain text control with no memory of past
searches. Swap it for a wxComboBox (a wxTextEntry, like wxTextCtrl,
so the existing GetValue()/Clear() call sites keep working via that
shared base) and persist submitted terms to wxConfig, most-recent
first, capped at 20 entries and deduplicated case-insensitively.

Right-clicking the field opens a small menu ("Remember search
history" checkbox + "Clear search history") so history can be paused
or wiped without a dedicated Preferences page.

i18n: ran scripts/update-po.sh to register the two new menu strings.

* style(search): separate the destructive Clear item from the toggle above

A separator between the checkbox and "Clear search history" keeps the
one-shot destructive action visually distinct from the persistent
on/off state, instead of reading as a second toggle in the same group.

* style(search): use nullptr instead of NULL for the new combo box

Fixes the modernize-use-nullptr clang-tidy finding on the changed
line; matches the nullptr convention already used a couple of
wxComboBox constructions below in the same file.

* feat(search): rework query history per amule-project#643 review — file, prefs toggle, edit menu

Addresses all four blocking points from got3nks's review, plus both
optional suggestions:

1. Edit context menu restored. Overriding the field's context menu no
   longer drops Cut/Copy/Paste/Select All -- same custom-Paste-ID idiom
   as CMuleTextCtrl::OnRightDown (wxMenu over-permits wxID_PASTE, so it
   gets a manual clipboard-content check), plus a separator, plus the
   history's own Clear action.

2. Persisted to a dedicated searchhistory.dat (via CTextFile, one term
   per line) instead of amule.conf -- mirrors eMule's AC_SearchStrings.dat.
   Query terms no longer bloat the main config or travel with config
   backups / the --amule-config-file push to amuleweb/amuleapi.

3. "Remember search history" moved into Preferences > General as an
   ordinary Cfg_Bool checkbox (IDC_SEARCHHISTORYENABLED), same
   NewCfgItem wiring as every other GUI-behavior toggle on that page.
   It's a client-side-only setting, so the one checkbox works unchanged
   in both amule and amuleGUI. The context menu keeps only Clear (a
   one-shot action, not a setting to toggle from a hidden menu).

4. Cap raised from 20 to 30, matching eMule's CCustomAutoComplete default.

Optional, done anyway:
- wxComboBox::AutoComplete() wired up (eMule's ACO_AUTOSUGGEST
  equivalent), re-armed after every load/record/clear so it always
  reflects the current entry set.
- Explicitly framed as *query* history throughout (comments, tooltip)
  to distinguish it from the separate, not-yet-implemented result
  persistence that's the rest of amule-project#641.

The dedup/move-to-front/cap logic that used to live inline in
CSearchDlg::RecordSearchHistory is extracted into a pure function,
ApplySearchHistoryEntry() (SearchHistory.h/.cpp), decoupled from
wxComboBox/wxConfig specifically so it's unit-testable without a wx
event loop -- new SearchHistoryTest covers empty-list insert, reorder
of an existing term, case-insensitive dedup, empty-term no-op, and
capping (including locking in the actual 30-entry constant).

Rebased onto current master; po/ catalogs regenerated as the final
step so the diff is just the new/changed strings in sync with the tree.

Verified for real: built and ran both amule and amulegui, plus the
full unit test suite (27/27 passing, including the new
SearchHistoryTest's 7 cases).

* fix(tests): link Format.cpp + strerror_r.c into SearchHistoryTest

Same Linux/mingw-only link failure as CMuleCollectionTest/MagnetURITest
already work around: muleunit's MuleDebug.cpp needs CFormat for its
glibc backtrace path, which isn't compiled in on macOS -- so the
target linked fine locally but failed on the Ubuntu/mingw CI builds
(and the clang-tidy jobs, which build the tree first).

* i18n: regenerate po/ catalogs after rebasing onto current master

Mechanical rebase to resolve the po/ catalog conflicts against master's
amule-project#648/amule-project#650/amule-project#651 (per got3nks's note on amule-project#643) -- no source changes here,
scripts/update-po.sh output only, so the diff is just the tree back in
sync with the current strings.

* fix(search): avoid an unnamed EReadTextFile bitmask cast in history load

txtIgnoreEmptyLines|txtStripWhitespace has no single named enumerator
to cast to -- clang-tidy Tier-1 flagged it (clang-analyzer-optin.core.
EnumCastOutOfRange), correctly: EReadTextFile isn't a flag enum, so a
synthesized OR'd value is genuinely out of its declared range even
though CTextFile::ReadLines treats it as bitflags at runtime.

txtReadDefault would dodge the cast but also drops '#'-led lines,
silently eating a legitimate search term that happens to start with
one. Read unfiltered (txtReadAll, a real enumerator) and do the
trim/empty-line-drop by hand instead -- same behavior, no cast, no
lost terms.

* i18n: regenerate po/ catalogs after rebasing onto current master

Mechanical rebase to resolve the po/ conflicts against master's amule-project#642
(just merged) -- no source changes here.