ui: theme-aware list-control colours (drop hardcoded *wxBLACK/BLUE/RED) - #179

PR amule-project#128 fixed the *wxBLUE sweep in muuli_wdr.cpp's dialog stat labels
but didn't touch the custom DC drawing inside the list controls. Two
classes of bug were left in src/GenericClientListCtrl.cpp and
src/SearchListCtrl.cpp:

1. Hardcoded text / pen colours that render fine on the default light
   theme but are unreadable on Adwaita-dark / macOS dark / KDE Breeze
   Dark.

2. SearchListCtrl's state-coding logic that overlays per-channel tints
   (`green = 255` for DOWNLOADED, `red = 255` for QUEUED, ...) on top
   of a base initialised from wxSYS_COLOUR_WINDOWTEXT. On light themes
   the base is black so the tints produce green / red / magenta as
   intended; on dark themes the base is white-ish, so the channel
   assignments are no-ops and *every state collapses to the same
   colour* -- the semantic cue disappears entirely.

Five sites updated:

  - GenericClientListCtrl.cpp:1004 + :1008 (A4AF badge text + border)
    -> wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOWTEXT). Pure
    decoration, no semantic meaning -- just needs to be readable.

  - GenericClientListCtrl.cpp:1042 (queue rank decreased, was *wxBLUE)
    -> hand-tuned blue per theme: (120,170,255) on dark, (0,80,200)
    on light.

  - GenericClientListCtrl.cpp:1045 (queue rank increased, was *wxRED)
    -> hand-tuned red per theme: (255,100,100) on dark, (220,0,0) on
    light.

  - GenericClientListCtrl.cpp:1130 (filename mismatch, was *wxRED)
    -> same red palette as above.

  - SearchListCtrl.cpp::362-389 (search result state palette) ->
    replace the channel-tweak logic with explicit per-state palette
    branching:
      DOWNLOADED  green   (80,220,80) / (0,160,0)
      QUEUED      red     (255,100,100) / (220,0,0)
      CANCELED    magenta (255,120,200) / (180,0,180)
      new         blue gradient by source count, inverted on dark

Primitive used at every draw / refresh site:

    const bool isDark = wxSystemSettings::GetAppearance().IsDark();

Called per-paint, not cached at startup -- a runtime theme toggle
takes effect on the next list refresh. wxSystemAppearance::IsDark()
queries:
  - macOS: NSAppearance bestMatchFromAppearancesWithNames against the
    dark aqua appearance.
  - Windows: AppsUseLightTheme registry value.
  - wxGTK: gtk-application-prefer-dark-theme, with WCAG-style
    luminance of wxSYS_COLOUR_WINDOW as fallback.

Available since wxWidgets 3.1.3, so safely in our 3.2 minimum.

Three other call sites surveyed and intentionally left alone:
  - CaptchaGenerator.cpp:53 (*wxBLACK on *wxWHITE_BRUSH bitmap)
    drawing onto a known-white surface; theme is irrelevant.
  - DownloadListCtrl.cpp:1035 / :1037 (wxWHITE / wxBLACK for the
    percentage label over the progress bar) contrast keyed off the
    bar's own hardcoded fill colour, not the system background.

Closes amule-project#177