siso: restore mtimes only for directories Flush actually wrote

When Flush writes a directory's members to disk, those writes bump the
directory's on-disk mtime. Flush therefore sets the directory's mtime
back to the recorded value afterwards, so that the next build sees the
directory as unchanged.

The bug: Flush queued a directory for this mtime restore as soon as it
saw the entry, before the lready check that decides whether there is
anything to write at all. So even directories that Flush then skipped
got their mtime rewritten. That is wrong in two ways:

- Flush also runs on inputs (prepareLocalInputs), so source
  directories pass through it. If the user changed such a directory
  during the build, for example by adding a file, the restore reset
  its mtime to the old recorded value. updateDir then saw no change,
  and the new file stayed invisible to ReadDir and Glob.
- If the path on disk had changed type in the meantime, Flush rewrote
  the mtime of whatever now sits at that path, for example a user's
  source file.

Now Flush queues a directory for the mtime restore only when flushDir
actually wrote it, plus one more case: generated directories (cmdhash
set) that are already local-ready. For those, a trailing-slash flush
can still write missing members beneath them, which bumps the on-disk
mtime. Without the restore the saved state no longer matches disk, and
the next build sees entryBeforeLocal and re-runs the producing step
for nothing. Source directories (no cmdhash) never get their mtime
rewritten, so a user's mid-build change stays visible; see
TestFlush_LocalReadyDirMtimeNotRestored.

Change-Id: If04f07c6a5ce04eda3b316107dfbaa6440dc933c
Reviewed-on: https://chromium-review.googlesource.com/c/build/+/8037821
Commit-Queue: Neri Marschik <nerima@google.com>
Reviewed-by: Yuke Liao <liaoyuke@google.com>
Auto-Submit: Philipp Wollermann <philwo@google.com>