git status --deserialize can report stale results if excludes file is modified

[jeffhostetler]

When changes are made to the global excludes file (defaults to "$XDG_HOME/git/excludes") or
the repo-local excludes file (".git/info/excludes"), an existing status serialization cache should be
invalidated and subsequent "git status --deserialize" should reject it and fallback to a normal
(scanning) status run.

Changes in either of these files can change the result of "git status" when there are untracked
or ignored files present in the workdir. The status serialization cache file contains results for
untracked and ignored files relative to the exclude settings when "git status --serialize" was
executed. When either of these files change, the cached results should be discarded.

Add metadata for user-global and repo-local excludes-files to the status serialization header
(like we do for the .git/index mtime). Use this to invalidate the status cache if either excludes-file
changes and cause "git status --deserialize" to reject the cache and fallback to a normal status run.

The GVFS service daemone watches for changes to files within the projected workdir and will
invalidate the status cache appropriately. This includes watching for changes to the various
per-directory .gitignore files.

The issue here is necessary because the 2 excludes file are outside the workdir and primarily
for the global excludes file since the pathname can come from the "core.excludesFile" config
setting.

Limitations: "git status --deserialize" will not invalidate the status cache if any of the
per-directory .gitignore files are changed or if there are any other changes within the
workdir. Therefore, it may report stale results. "git status --deserialize" would need
something similar to the full untracked-cache index extension (that records the directory
mtimes) to detect that. We don't use the untracked-cache here because one of the goals
of the status serialization feature was to avoid reading the index (in addition to unnecessary
disk scanning). This is only possible because the GVFS service daemon handles these cases
for us.

[jeffhostetler]

See PR #1.

[jeffhostetler]

Closing this now as PR #1 building.