fix: stop the remaining iter_*_dirs yielding duplicate or joined paths

[darrenhuai]

iter_config_dirs and iter_data_dirs stopped yielding the same directory twice in #469, for the case where use_site_for_root redirects the user dirs to their site equivalents. The cache, state, log and runtime families were left on the base implementation in PlatformDirsABC, so they still do it. As root with use_site_for_root=True:

iter_cache_dirs      ['/var/cache/foo', '/var/cache/foo']
iter_state_dirs      ['/var/lib/foo',   '/var/lib/foo']
iter_log_dirs        ['/var/log/foo',   '/var/log/foo']
iter_runtime_dirs    ['/run/foo',       '/run/foo']

By that point user_cache_dir and friends already return the site path, and the base implementation yields it a second time.

While writing tests for that I ran into a second one on macOS. site_cache_dir joins the Homebrew entry and /Library/Caches with os.pathsep when multipath is set, so iter_cache_dirs handed back a single string holding two paths, and iter_cache_paths turned it into Path('/opt/homebrew/var/cache/foo:/Library/Caches/foo'). iter_data_dirs splits properly because _site_data_dirs already exists as a list; cache had no equivalent. Added _site_cache_dirs in the same shape and had site_cache_dir format from it, so its own output is unchanged.

Neither case shows up in a default configuration — use_site_for_root is off by default, and the macOS one needs both Homebrew and multipath — so this is latent rather than something callers are likely to have hit.

On the tests: each of the four Unix iterators gets a no-duplicates check as root and a counterpart as non-root, so a fix that simply dropped the user dir would fail the second one. macOS covers iter_cache_dirs under Homebrew with multipath set and unset, plus iter_cache_paths to pin down the Path behaviour.