TargetStartedEventArgs could have fields for inputs/outputs

From an email I got:

> There’s of course a bunch of badly authored targets that always build, causing a chain of downstream projects to rebuild. But to go after the ones causing the most damage to get the most bang for the buck, I want to try and extract the “invalidation chain” and attack from the root forward. Sometimes the links are clear in the build log, eg. “Referenced.dll is newer than Referer.dll”. Other times less so, eg. “.CoreCompileInputs.cache is newer than MyProgram.exe” and CoreCompileInputs includes a bunch of autogenerated .cs files (which one changed?).
>
> Are there any tools/tricks to perform such an analysis? I think it should be possible from mining the binary build log with code, but before I set out trying that I wanted to check if there are better ways or whether you have any tips on how to go about it.

Such analysis would be much easier if you didn't have to parse out the inputs/outputs to build the graph.

On the other hand, we don't want to bloat the events with data that isn't likely to be used. We'll have to think about tradeoffs.