storage: support resumable uploads

## Do not merge

- [x] Allow a choice in `upload` and `createWriteStream` between simple/resumable upload technique
- [x] `upload`: Stat the incoming file for size, default to simple for < 5mb, resumable for > 5mb
- [x] `createWriteStream`: default to resumable uploads
- [x] Integrate { resumableThreshold: n } option on storage instantiation (defaults to 5mb)

RE: #298

`createWriteStream` uses the Resumable Upload API: http://goo.gl/jb0e9D.

The process involves these steps:

1. POST the file's metadata. We get a resumable upload URI back, then cache it with ConfigStore.
2. PUT data to that URI with a Content-Range header noting what position the data is beginning from. We also cache, at most, the first 16 bytes of the data being uploaded.
3. Delete the ConfigStore cache after the upload completes.

If the initial upload operation is interrupted, the next time the user uploads the file, these steps occur:

1. Detect the presence of a cached URI in ConfigStore.
2. Make an empty PUT request to that URI to get the last byte written to the remote file.
3. PUT data to the URI starting from the first byte after the last byte returned from the call above.

If the user tries to upload entirely different data to the remote file:

1. -- same as above --
2. -- same as above --
3. -- same as above --
4. Compare the first chunk of the new data with the chunk in cache. If it's different, start a new resumable upload (Step 1 of the first example).
It's likely if we can write to the file at the opening of the method, we can delete it. I think the severity of it not being able to read, write, or delete the config file, which is *the only way a resumable upload can work*, is a good throw case. The error handler should be for consistent API errors. I would worry it gets confusing if we start having our own custom errors a user has to handle, and if they do get this error - I'm not sure how they would handle it from runtime without human attention.