SharedDir: recursive vs explicit intent split + cold-discover + UI polish (#391) - #606

The watcher's existing RegisterNewSubdirectory path catches new
subdirectories of a shared root when they're created at runtime
(HOT case) -- a wxFSW_EVENT_CREATE fires, the handler adds the
path to shareddir_list, persists shareddir.dat, and starts watching
the new subdir. That's the "auto-share new subdirs of watched
parents" behaviour the watcher PR shipped.

The COLD case had no equivalent: subdirectories that grew on disk
while aMule was offline never fire a CREATE (they exist before the
watcher attaches), so a /Music share whose disk gained three new
albums in the interim would never see them until each album
happened to gain a new file via some other path. That's the
follow-up reported on amule-project#391.

Add ColdDiscoverSubdirs(), called once from Enable() right after
the initial RegisterAllPaths(). For each path in shareddir_list it
recursively walks the subtree (CDirIterator::Dir) and collects
subdirectories not yet in shareddir_list, then in a single batch:
appends them to shareddir_list, calls m_watcher->Add() on each
(Linux/BSD/Windows -- macOS's enclosing FSEvents stream already
covers descendants), persists shareddir.dat once, and
ScheduleReload()s so the in-memory shared-file list picks up files
under the new subdirs without blocking Enable().

Deliberately NOT called from Refresh(): on macOS the watcher
writes the symlink-resolved form ("/private/tmp/...") while
CDirIterator over a /tmp-rooted shareddir.dat entry produces the
unresolved form ("/tmp/..."), so a second walk after runtime
RegisterNewSubdirectory wrote one form would add the other form
again. shareddir.dat ended up with duplicate entries for the same
subdir. Cold-discovery is genuinely a startup concern -- the HOT
path handles every runtime case after Enable.

Membership index is a std::set<wxString> over raw path strings,
matching the comparison shape the rest of the file uses. The
walker recurses through known subdirs as well as unknown ones, so
a tree whose top layer is in shareddir.dat but whose deeper layers
aren't still gets fully covered in a single pass.

Verified on macOS: shareddir.dat with just "/tmp/cold-test-root/"
plus two pre-existing album subdirs on disk -> on start, both
albums get appended to shareddir.dat and the share scan picks up
their files after the 5-second debounce. shareddir.dat after run
contains the root plus both subdirs, no duplicates.

The previous commit's cold-discovery (and the existing amule-project#591 watcher
RegisterNewSubdirectory) auto-added new subdirectories to every
shared dir indiscriminately. There was no way to express "share
/Music but NOT its sensitive nested subfolders" -- the moment a new
subdir appeared under any shared root it became part of the share.
Desktop users with sensitive nested folders inside a shared root
were exposed.

This commit introduces a per-root recursive flag, persisted in a
new shareddir-recursive.dat file. The watcher and cold-discovery
now gate their auto-add behaviour on "ancestor is recursive": only
roots the user has explicitly marked recursive via the UI's right-
click "share subdirectories recursively" automatically include
new/existing subdirectories. Non-recursive shares stay strict.

Three on-disk files going forward:

* shareddir-recursive.dat (new): roots the user marked recursive.
* shareddir-explicit.dat (new): roots the user added explicitly,
  without recursion.
* shareddir.dat (existing): regenerated as the runtime union for
  backwards compatibility -- older binaries and external scripts
  that read or write this file see the same effective list as
  before.

`CPreferences::shareddir_list` (the in-memory list the share scan,
watcher, etc. read as authoritative) is recomputed at every
ReloadSharedFolders as `shareddir_explicit_list ∪ expand(shareddir_
recursive_list)`. The expansion walks each recursive root's subtree
(CDirIterator::Dir) and adds every existing descendant directory.

Migration: a pre-existing shareddir.dat with no
shareddir-{explicit,recursive}.dat is loaded entirely into the
explicit list. Existing users keep their path set but stop silently
auto-recursing -- they opt back in per-root via the UI. Safe
default for desktop users.

Reconciliation runs on every Reload (startup, EC reload, UI
reload, watcher-debounced reload), not just startup. Diffs the
on-disk shareddir.dat against the expected union; entries written
externally (Docker entrypoints, sysadmin edits, old-binary writes)
are imported into shareddir_explicit_list, and entries the
external writer removed are dropped from explicit (entries that
came from the recursive expansion are left alone -- the user's
recursive intent overrides single-entry external edits).

UI side: PrefsUnifiedDlg::CommitSharedDirsWithProgress already
extracted explicit vs recursive intents from the DirectoryTreeCtrl
(GetSharedDirectories vs GetRecursiveSharedDirectories). The
commit path now assigns each to its dedicated Preferences list
instead of conflating them into shareddir_list, and the cancel
rollback restores all three. Initial dialog state loads from the
two intent lists rather than the runtime union (which would
otherwise render auto-discovered subdirs as user-selected items).

Watcher side: CSharedDirWatcher::RegisterNewSubdirectory and
::ColdDiscoverSubdirs both check
CPreferences::IsRecursiveAncestor() before adding. Explicit shares
no longer accumulate subdirs at runtime; recursive shares behave
as before.

Verified on macOS with a three-mode smoke test:

* `recursive-root` (in shareddir-recursive.dat) with pre-existing
  subA/subB: both auto-expand into shareddir.dat at startup;
  recursive-root/rec-hot created at runtime is auto-added.
* `explicit-root` (in shareddir-explicit.dat) with pre-existing
  subC: subC NOT in shareddir.dat; explicit-root/exp-hot created
  at runtime NOT added.
* `script-added-dir` written to shareddir.dat externally
  (Docker-entrypoint pattern): imported into
  shareddir-explicit.dat on next boot, survives subsequent
  shareddir.dat regenerations.

No file format change to shareddir.dat (still one path per line);
the new files use the same format. Older binaries that ignore
the new files continue to operate against shareddir.dat as the
union, with the caveat that recursive intent is lost when an
older binary round-trips shareddir.dat (the markers in
shareddir-recursive.dat survive untouched because the old binary
doesn't read or write that file).

SetSharedDirectories already calls UpdateSharedDirectories when the
tree is initialised; SetRecursiveSharedDirectories didn't, so a
prefs-open that loaded both lists in sequence only refreshed for
the explicit set. Recursive roots loaded from shareddir-recursive.dat
appeared un-bold on first paint until the user expanded the branch
(at which point AddChildItem's IsRecursiveShare/IsInsideRecursiveShare
check kicked in). Mirror the symmetry.