Script access to changed/added/removed files

Since Wireit knows which input files were changed, added, and removed between each run of a script, it makes sense to allow scripts to directly access that information to help them run incrementally. Any program which takes a list of files on `stdin` or in `argv` could benefit from this feature.

For example, an eslint script could be configured to only lint the files that were changed or added since its last successful run, and run much faster (eslint actually has a [feature](https://eslint.org/docs/user-guide/command-line-interface#caching) like this built-in, but using it with Wireit means duplicating all the work of computing changed files).

Here are a few ideas for how we could allow scripts to access changed file data:

### Environment variable

```json
"lint": {
"command": "cat ${WIREIT_FILES_CHANGED} ${WIREIT_FILES_ADDED} | xargs eslint",
"files": [
"src/**/*.ts"
],
"output": []
}
```

This would work by creating `.wireit//(changed|added|removed)` files before executing a script, and setting the `$WIREIT_FILES_(CHANGED|ADDED|REMOVED)` environment variables to those paths.

Pro: Seems like the simplest solution.

Con: We'd write these files even they aren't being consumed (though it could require opting-in with a setting).

### Binary

The Wireit binary itself could print changed/added/removed files when it is called with a particular parameter. As usual, it would use the `npm_lifecycle_event` environment variable to figure out the context.

```json
"lint": {
"command": "wireit files changed added | xargs eslint",
"files": [
"src/**/*.ts"
],
"output": []
}
```

Con: Extra binary invocation. To prevent duplicating delta calculations, we would want to coordinate between the main and child wireit processes, probably by writing the changed files to the `.wireit/<script>/(changed|added|removed)`.

### Stdin pipe

```json
"lint": {
"command": "xargs eslint",
"files": [
"src/**/*.ts"
],
"stdin": {
"files-changed": true,
"files-added": true
},
"output": []
}
```

Pro: Syntax is the same on Windows vs Linux/macOS, since Windows environment variable and pipe syntax is different. I don't think we should make decisions based on this though, this is just a perennial problem with how npm supports multiple shells.

Con: Less flexible than the other options. The other options allow specifying exactly where and how the input files are read in the shell command. Feels like the most complex in terms of the configuration syntax.