sharedfiles: auto-rescan via wxFileSystemWatcher - #591

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).

The previous commit's cold-discovery (and the existing #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).

CSharedDirWatcher::RegisterAllPaths() previously subscribed only the
explicit shareddir_list to the wxFileSystemWatcher backend. But
CSharedFileList::Reload() treats three sources as shared (around
SharedFileList.cpp:370):

  1) the global Incoming dir   (thePrefs::GetIncomingDir())
  2) each category's Incoming  (theApp->glob_prefs->GetCatPath(i),
                                i = 1 .. GetCatCount()-1)
  3) the explicit shareddir_list

So the auto-rescan introduced in #591 was missing (1) and (2):

* A file dropped into ~/.aMule/Incoming did not trigger the watcher
  -> the file never appeared in Shared until some unrelated CREATE
  fired elsewhere in the watched tree and incidentally rescanned.
* Same story for any category-specific incoming dir.

Reproducer from #741:

  echo 123456 > ~/.aMule/Incoming/file_in_Incoming
  # wait — never auto-shared
  echo 654321 > ~/.aMule/extra/file_in_extra   # (extra is shared)
  # both files appear in Shared within seconds

Completed downloads aren't affected: CPartFile signals the scanner
directly when a file transitions to Incoming, so end-of-transfer
sharing keeps working. The bug only bites manual / external drops
into Incoming, which is exactly the case #741 walks through.

Fix: build the effective watch list by mirroring Reload()'s three
sources (Incoming + cat paths + shareddir_list), deduplicating
by GetRaw() so a user who happened to also list Incoming as an
explicit shared dir doesn't get a duplicate watch registration.
The dedup matters on Linux/BSD/Windows (per-dir Add()) and on
macOS (FSEvents rejects overlapping AddTree streams; an explicit
ancestor + Incoming-as-descendant still gets pruned by the existing
covered_by_ancestor logic further down).

Reported by @danim7 (#741).