amule-remote-gui: surface EC_OP_FAILED from EC_OP_ADD_LINK to the user - #557

…ct#310)

Adds a batch CDownloadQueue::AddLinks / CDownQueueRem::AddLinks
abstraction and routes the GUI's batch callers (Fast eD2k paste box,
.emulecollection import) through it. Centralises the popup aggregation
logic and fixes both monolithic *and* amulegui in one move.

Background:
PR amule-project#557 made amulegui's CAddLinkHandler pop a wxMessageBox so an
EC_OP_FAILED reply from EC_OP_ADD_LINK surfaces to the user instead of
being silently dropped (amule-project#310). The same regression existed in the
monolithic amule binary: CDownloadQueue::AddLink logs the failure via
AddLogLineC and returns false, but no UI feedback ever reaches the
user.

The naive fix -- popping a wxMessageBox inside AddLink -- produces N
dialogs when the user pastes N invalid lines into the Fast eD2k box.
PR amule-project#551 had already taught amuled's EC handler to accept N tags in one
EC_OP_ADD_LINK packet and emit a single aggregated EC_OP_FAILED
response, but amulegui's CDownQueueRem::AddLink was still looping
client-side and sending one packet per link, so CAddLinkHandler still
fired once per failure.

Change:
1. CDownloadQueue::AddLinks(wxArrayString, cat)
   Calls AddLink in a loop, counts failures, dispatches a single
   wxPLURAL'd ShowAlert at the end. ShowAlert is polymorphic
   (wxMessageBox under amule, log-only under amuled), so the same
   code is safe to compile into the daemon.

2. CDownQueueRem::AddLinks(wxArrayString, cat)
   Packs the entire batch into one EC_OP_ADD_LINK packet (one child
   tag per link, EC_TAG_PARTFILE_CAT carrying the category). Daemon
   aggregates per PR amule-project#551; CAddLinkHandler fires exactly once with
   the existing catalog string ("%d of %d links failed...").

3. The two uniform-cat batch callers now call AddLinks instead of
   looping AddLink:
     - CamuleDlg::OnBnClickedFast (Fast eD2k paste box)
     - CSharedFilesCtrl::OnAddCollection (.emulecollection import)

4. CamuleAppCommon::AddLinksFromFile (ED2KLinks-in-config-dir poller)
   keeps its own per-line counter + AddLink-in-loop because each line
   may carry its own ":CAT" suffix, which doesn't fit the single-cat
   AddLinks signature. Rare path, rare feature -- left alone.

CDownloadQueue::AddLink itself is untouched; it still logs the
protocol-specific reason per failure, which the aggregated popup
intentionally points to ("see log for details") rather than duplicating
inline.

Adds a batch CDownloadQueue::AddLinks / CDownQueueRem::AddLinks
abstraction and routes the GUI's batch callers (Fast eD2k paste box,
.emulecollection import) through it. Centralises the popup aggregation
logic and fixes both monolithic *and* amulegui in one move.

Background:
PR #557 made amulegui's CAddLinkHandler pop a wxMessageBox so an
EC_OP_FAILED reply from EC_OP_ADD_LINK surfaces to the user instead of
being silently dropped (#310). The same regression existed in the
monolithic amule binary: CDownloadQueue::AddLink logs the failure via
AddLogLineC and returns false, but no UI feedback ever reaches the
user.

The naive fix -- popping a wxMessageBox inside AddLink -- produces N
dialogs when the user pastes N invalid lines into the Fast eD2k box.
PR #551 had already taught amuled's EC handler to accept N tags in one
EC_OP_ADD_LINK packet and emit a single aggregated EC_OP_FAILED
response, but amulegui's CDownQueueRem::AddLink was still looping
client-side and sending one packet per link, so CAddLinkHandler still
fired once per failure.

Change:
1. CDownloadQueue::AddLinks(wxArrayString, cat)
   Calls AddLink in a loop, counts failures, dispatches a single
   wxPLURAL'd ShowAlert at the end. ShowAlert is polymorphic
   (wxMessageBox under amule, log-only under amuled), so the same
   code is safe to compile into the daemon.

2. CDownQueueRem::AddLinks(wxArrayString, cat)
   Packs the entire batch into one EC_OP_ADD_LINK packet (one child
   tag per link, EC_TAG_PARTFILE_CAT carrying the category). Daemon
   aggregates per PR #551; CAddLinkHandler fires exactly once with
   the existing catalog string ("%d of %d links failed...").

3. The two uniform-cat batch callers now call AddLinks instead of
   looping AddLink:
     - CamuleDlg::OnBnClickedFast (Fast eD2k paste box)
     - CSharedFilesCtrl::OnAddCollection (.emulecollection import)

4. CamuleAppCommon::AddLinksFromFile (ED2KLinks-in-config-dir poller)
   keeps its own per-line counter + AddLink-in-loop because each line
   may carry its own ":CAT" suffix, which doesn't fit the single-cat
   AddLinks signature. Rare path, rare feature -- left alone.

CDownloadQueue::AddLink itself is untouched; it still logs the
protocol-specific reason per failure, which the aggregated popup
intentionally points to ("see log for details") rather than duplicating
inline.

…er (amule-project#557)

Follow-up to amule-project#554. Jwt.cpp and Api.cpp each carried an identical include block -- a PICOJSON_USE_INT64 define plus the #ifdef AMULE_PICOJSON_HEADER selection. Since PICOJSON_USE_INT64 changes the layout of picojson::value, the two use sites drifting apart would be an ODR violation the compiler cannot catch.

Move both to src/libwebcommon/PicoJson_Inc.h, a single guarded include site, mirroring the existing CryptoPP_Inc.h wrapper. Both TUs now include "PicoJson_Inc.h", so the int64 toggle and the bundled/system header selection have one source of truth. No behaviour change; verified with clean bundled and system builds, JwtTest passing in both.