Each call to `projectile-cache-current-file' under persistent caching
scheduled a fresh 30-second idle timer that closed over a snapshot of
the file list at scheduling time.  Opening N files in a session
queued N timers; once Emacs went idle they all fired and serialized
the cache N times, with the earlier ones writing stale (shorter)
lists.

Maintain a per-project pending timer in
`projectile--pending-cache-flush-timers' instead, cancelling and
rescheduling on each new file.  The fired callback re-reads the
current in-memory cache, so the disk write reflects the final state
rather than whichever snapshot the last timer captured.

Previously the persistent invalidate path called
`(projectile-serialize nil ...)', leaving a four-byte file containing
the literal "nil" on disk.  Resolving the long-standing TODO: just
delete the file when invalidating, so the on-disk state matches the
intent of the command (and so an orphaned cache file isn't left
behind on uninstall).

`projectile-purge-file-from-cache' writes the updated file list to
disk under persistent caching; the directory variant only mutated
the in-memory hash, so the purged subtree would reappear on the
next Emacs session.  Mirror the persistence step here.

Without this, `projectile-files-cache-expire' combined with persistent
caching ended up re-reading the cache file from disk on every call to
`projectile-project-files' and never reindexing: the TTL check at the
top of `projectile-project-files' evicts the in-memory entry whenever
its cache time is missing, and `projectile-load-project-cache' was
populating only `projectile-projects-cache' on disk loads.  Use the
cache file's mtime as the recorded time, so the TTL check sees a real
age and reindexing happens when (and only when) the data is actually
stale.

Final indexing review batch: cleanup, tests, docs

Three doc gaps surfaced during the indexing review:

* The `*' prefix on `projectile-globally-ignored-directories' entries
  is not a glob - it is what promotes a basename match from
  "anchored at the project root" to "anywhere in the tree", and it
  only takes effect under hybrid indexing.
* The default `projectile-generic-command' picks `fd' when it's on
  PATH and falls back to a `find ... | tr ...' pipeline. The
  fallback does not exclude common build directories, which is a
  trap for non-VCS projects under alien on hosts without `fd'.
* `projectile-git-use-fd' controls how Projectile handles
  deleted-but-unstaged files: with `fd' they disappear immediately,
  with `git ls-files' Projectile post-filters via `git ls-files -zd'.

`projectile-get-ext-command' had no direct test coverage, so the
non-git VCS branches (hg/svn/bzr/darcs/fossil/pijul/sapling/jj) were
relying on indirect coverage that didn't actually exercise the
dispatch. Add a `describe' block that pins each branch.

Also extend the `projectile-dir-files-alien' tests with two cases
that were previously uncovered: the fd path for git (verifying we
don't also call `projectile-git-deleted-files') and the no-VCS
fallback (verifying the generic command is used).

`projectile-get-immediate-sub-projects' was unconditionally shelling
out to `git submodule --quiet foreach ...' on every indexing call for
git projects, even when the project had no submodules at all. For
monorepos that re-index the project root often this is pure overhead.

Use `locate-dominating-file' to look for `.gitmodules' along the
parent chain (PATH may be inside a git repo without being its
toplevel) and skip the shell-out when none is found.

Also tighten `projectile-discover-projects-in-directory' to filter
`.' / `..' via `directory-files-no-dot-files-regexp' instead of a
post-filter `member' check, matching the indexing walker's style.

Speed up indexing's ignore filtering

Cover the new internal helpers (`projectile--list->set',
`projectile--ignored-file-fast-p', `projectile--ignored-directory-
fast-p') and add end-to-end tests for the previously uncovered
behaviour:

* `projectile-index-directory' honors dirconfig glob ignore patterns
  at every directory level - previously only the alien-mode dirconfig
  warning had any test coverage for this.
* Ensure (`!') entries in `.projectile' override an ignore pattern.
* `projectile-remove-ignored' drops basename matches, treats `*'-
  prefixed ignored-dir entries as any-segment matches, and treats
  plain entries as path-prefix matches.