ServerUDPSocket: demote "additional packet" notice to non-critical debug - #548

The deferred/tail scroll called ScrollToEnd() directly. With word-wrap on --
where Scintilla lays out wrapped lines incrementally over several idles -- two
problems fell out:

- switching to a hidden log pane after the backlog loaded landed a few lines
  short (the single scroll ran before the tail was wrapped); and
- switching to it mid-load landed at ~90%, because the batch tail-scroll and
  the idle re-scroll loop both moved the view and the loop misread its own
  batch scroll as a manual scroll and gave up.

Make OnInternalIdle() the sole scroller: ScrollToBottom() only sets a pending
flag, and the idle loop re-applies ScrollToEnd() until the first-visible line
stops moving (wrap settled at the true bottom), bailing only when the view
moves on its own (a real manual scroll). Appends never move the first-visible
line, so the loop follows the growing log through the whole replay. Lives in
the base CMuleLogCtrl, so all three panes (aMule Log, aMuleGUI Log, server
info) share it. Follow-up to amule-project#548 (issue amule-project#547).

The deferred/tail scroll called ScrollToEnd() directly. With word-wrap on --
where Scintilla lays out wrapped lines incrementally over several idles -- two
problems fell out:

- switching to a hidden log pane after the backlog loaded landed a few lines
  short (the single scroll ran before the tail was wrapped); and
- switching to it mid-load landed at ~90%, because the batch tail-scroll and
  the idle re-scroll loop both moved the view and the loop misread its own
  batch scroll as a manual scroll and gave up.

Make OnInternalIdle() the sole scroller: ScrollToBottom() only sets a pending
flag, and the idle loop re-applies ScrollToEnd() until the first-visible line
stops moving (wrap settled at the true bottom), bailing only when the view
moves on its own (a real manual scroll). Appends never move the first-visible
line, so the loop follows the growing log through the whole replay. Lives in
the base CMuleLogCtrl, so all three panes (aMule Log, aMuleGUI Log, server
info) share it. Follow-up to amule-project#548 (issue amule-project#547).

…le-project#548)

The amuleGUI log panes used a wxTE_RICH2 (RichEdit) control, which holds the
whole document and reflows O(n) on scroll, so a remote-GUI first-sync backlog
of tens of thousands of daemon-log lines made scrolling crawl and mispaint
(only the tail visible until a manual scroll).

Replace the three log/info panes (aMule Log, aMuleGUI Log, server info) with a
new CMuleLogCtrl backed by wxStyledTextCtrl (Scintilla), which renders only the
visible lines: full history is kept and scrolling stays O(visible) at any size,
with character-level selection/find preserved. Lines word-wrap; critical lines
are bold via per-line styles. Tail-scroll only fires when already at the bottom;
a scroll requested while the pane is hidden is deferred to the first idle once
it is on screen (in the base control, so all three panes share it). Removes the
RichEdit workaround stack (per-poll batching, the Freeze/Thaw lineage of
amule-project#451/amule-project#471/amule-project#477). The stc component ships with every platform's wxWidgets and is
requested only for the GUI library; the Windows portable bundles its DLL via the
existing GET_RUNTIME_DEPENDENCIES install step. Reported in amule-project#547.

…mule-project#549)

Follow-up to amule-project#548 (Scintilla log panes). The tail-scroll landed short when log
lines wrap, because Scintilla lays out wrapped lines incrementally over several
idles, so a one-shot ScrollToEnd() ran against a display-line count that did
not yet include the still-unwrapped tail. Switching in mid-load made it worse:
each poll's batch also scrolled directly and the idle re-scroll loop misread
its own batch scroll as a manual scroll and gave up (~90%).

Make OnInternalIdle() the sole scroller: ScrollToBottom() only flags a pending
scroll, and the idle loop re-applies ScrollToEnd() until the first-visible line
stops moving (wrap settled at the true bottom), bailing only on a genuine
manual scroll. Appends never move the first-visible line, so it follows the
whole replay. In the base CMuleLogCtrl, so all three panes share it. Also
corrects a few amule-project#548 comments the rework left inaccurate. Reported in amule-project#547.

…mule-project#570)

The log views migrated to wxStyledTextCtrl (Scintilla) in amule-project#548 paint
their colours from the system theme once, in the constructor. The native
wxTextCtrl they replaced followed the platform appearance automatically;
Scintilla does not, so a live light/dark switch left the three log panes
(aMule Log, aMuleGUI Log, Server Info) stuck in the previous theme's
colours while the rest of the UI re-themed. Re-apply the styles on
wxEVT_SYS_COLOUR_CHANGED so the panes track the appearance.

Also guard against a foreground/background that resolve with too little
contrast to read: on macOS the window/text system colours are
appearance-aware and, on some wx builds, come back near-identical, which
paints the whole log invisible (amule-project#569). When the pair is unreadable, keep
the theme's background and force a legible foreground from its
brightness. Windows/GTK return static, well-contrasted colours and are
unaffected.