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).
RE: gapitoken - I think it throwing was the right behavior. It couldn't proceed because we were loose cannons, giving it data we were hoping was valid. The responsibility is ours to give a library the right data, just as much as it is our users to use our library.

However, best practices can be put aside to allow the library to make the best decision for its unique situation. In my opinion, an error handler from a stream should handle an error with the upload (API failed).

All errors can be handled, throwing is just a technique for problems the user can't fix during runtime. And again, asking for a resumable upload and not getting one is a throw for me. If I forget to attach an `.on('error')` handler, the error will throw. And if I do listen for errors, the only thing a user could choose to do the second time to fix the problem is use a simple upload technique. But, I strongly believe we would never see code that does that, because if they know to handle that problem (a file can't be written), they wouldn't let the problem happen before running their application / would use simple uploads from the beginning.

If we document that we throw an error in situations where we can't store a file, and recommend simple uploads in those cases, I think we're giving the user enough recourse to solve the problem, which is the most important thing.

Also, you frequently say you want things to blow up. I'm pretty sure you use the bomb emoji, too, so I *thought* you were serious :)