Fix bug #6609 (Fast file replacement operations can be missed)

Dispatch a FileSystem "change" event even when a dir change yields empty added/removed lists - because there's a delay between the change occurring and the time we re-read the dir contents in response, we might see back-to-back changes (e.g. a delete-recreate pair) as a no-op even though something definitely changed. See #6609 for an example bug.

Updated docs to clarify the two different special cases of directory change events. (Also contains an unrelated small docs improvement in FileUtils).

ProjectManager already responds to this special case the way we'd want - it calls FileSyncManager and then does nothing else - so no code changes needed there.