Change incremental build to account for more kinds of state change than timestamps

**This issue is in the open design phase and is a part of the [project.json -> csproj ](https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/) conversion effort.**
### Incremental build in the face of globs

MSBuild only considers the set of items computed in the current build when deciding when to execute a target. When files are included via wildcard this can create a problem when deleting an input. The output will be up-to-date with all of the existing inputs but should be re-built because the set of inputs has changed.

We could address this by building a state store and using it to compare the current build inputs & outputs against the previous build. In order to accomplish this, we would need to complete the following:
- [ ] Identify a unique address for a target instance (each target instance needs to be uniquely identifiable and gets its own persisted incremental state).
- [ ] Figure out directory structure for where to save the caches (machine wide / per project, etc).
- [ ] Flesh out cache invalidation scenarios (e.g. command line changed, environment variables changed, etc). Stretch goal: re-build when properties change as well as inputs/outputs.
- [ ] Stretch goal: Unify the multiple incremental implementations in MSBuild.