Provide file streams instead of metadata to resolvers
I will flesh out this description out in time. There are lots of [little conversations](https://github.com/jaydenseric/apollo-upload-server/issues/12#issuecomment-324507848) about this hidden around.

### Ideal scenario

A new user fills in a registration form. Fields submitted include `username` (String), `password` (String) `avatar` (File), and `banner` (File). The files are 4 MB each.

The non-file fields can be validated in the resolver as soon as the request comes in to the server, while the uploads asynchronously stream in. It turns out the `username` is already taken, so a validation error is thrown and the request is aborted. The user gets immediate feedback without having to wait for the whole upload to complete, and the server is not unnecessary burdened.

Because the files are streams in the resolver, they can be individually forwarded into cloud storage, skipping temporary storage on the API server's memory or filesystem. This allows the first `avatar` file to begin uploading to cloud storage while the second second `banner` file is still being received by the API. Because the files are not stored on the API server, data security compliance is simpler.

### Thoughts

With this setup, a developer could even use different methods to store each file from a single request.

I think it is best to just substitute files for file streams in the resolvers; no more metadata. The API is less opinionated, easier to implement and less complicated to document. Users can extract whatever metadata is useful to the them from the streams.

To prevent file uploads from blocking the resolvers (as they do currently with formidable) we will probably need to provide a new `files` field in the multipart form sent from the client. This will contain a JSON array of all the file object paths, i.e. `["0.variables.avatar", "0.variables.banner"]`. It, along with the existing `operations` fields should be the very first fields in the multipart form, will all the files following. This will allow us to build an operations object with placeholder file streams to then pass into the GraphQL server and the resolvers. The form can then continue streaming up in parallel to the resolvers running; each file that gets parsed can be streamed into the relevant placeholder stream constructed earlier.

I suspect that to engineer the new system we might have to write a custom multipart form parser, because we need to create streams before the file fields are parsed and options like formidable only create streams as they are encountered. We might also be better off writing the new functionality directly into the GraphQL server middlewares.

Also, I think when we move to streams we should start using a new word like "blob" instead of "file", because people will be able to use any sort of binary data that can't JSON encode in their variables. Relevant: https://github.com/jaydenseric/extract-files/pull/2.