Speed up manifest source for large repos

[jonabc]

This PR take some steps to address the slow runtime of the manifest source when using a generated manifest strategy as opposed to a hardcoded file with dependency mappings. In a test repo with 54k files reported by git ls-files, the changes here dropped the runtime from so-long-I-ctrl-C'd to a max of 8s.

From some very inconclusive maths this also showed to reduce the time in small-medium sized projects; running the manifest tests with this change increased the assertions/s and reduced the overall runtime just a bit. Nothing super conclusive but it at least didn't increase the runtime 😄

1. use set intersection instead of checking file existence when getting all of the tracked files in a repo

The primary issue for large repos was the massive number of File.exist? calls that were being issued, one for every file coming from git ls-files. Verification that the file actually exists on disk is necessary because the tool can be run with deleted files that have not been committed, meaning that git ls-files can return files that don't exist.

By using set intersection and loading the entire file system under the project root into memory the runtime is drastically reduced at the expense of more memory usage. For the majority of projects this should be minimal, and for very large projects this should still be a reasonable tradeoff.

2. modify a single set to avoid object allocation/copy while determining file paths for each configured dependency

Using a single set with each_with_object instead of reduce results in less object allocations and set enumeration copies, which dropped another couple seconds after the above. It won't affect the memory increase caused from (1), but it does reduce runtimes a bit further.