Trigger a change event on a file when just its metadata is updated

On the Mac, when a file's metadata changes, we (may) trigger a change event only on that file's parent directory, but not on the file itself. This pull request causes such a metadata change to trigger a change event for the file itself.

The former behavior is problematic because the change event is actually fired only if there are (or could be) some added or removed files in the directory, and in this case there are not. If no change event is fired, then the `FileSyncManager` never runs, which is responsible to comparing the timestamps of open documents with their files, and updating the contents of editors (as well as the File object's cached contents and consistency hash) accordingly. With this change, an event is correctly fired for the "modified" file. 

This should partially address #6437 by allowing the `FileSyncManager` to correctly handle file changes as soon as they are detected; this is clearly preferable to showing the `CONTENTS_MODIFIED` error dialog at save time. 

It seems that the root cause of #6437 however is some external process updating metadata of the files being edited, but presumably not changing their contents. In this case, the user would still see an "external changes" conflict dialog from `FileSyncManager` if the editor is dirty, when ideally there would be none if *only* the file metadata has changed. This pull request does not address this issue. Although @peterflynn has some ideas about how to address this problem, the fix may be more complex than this tweak, and probably should wait for a later sprint.

CC @peterflynn @jasonsanjose @gruehle @njx @dangoor