Optional upload protocol extension:

Blobs can be large, devices (e.g. mobile phones) can have slow
uploads, or both.  Thus, it's nice to have an upload resume mechanism.

In a stat response, a server can return a JSON key
"alreadyHavePartially" with similar format to the spec-required "stat"
array.  Instead of just "blobRef" and "size", though, there's a
continuation key and blobref of the part that server already has:

...
   "alreadyHavePartially": [
      {"blobRef": "sha1-abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd",
       "size": 12312,
       "partBlobRef": "sha1-beefbeefbeefbeefbeefbeefbeefbeefbeefbeef"
       "resumeKey": "resume-sha1-abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd-12312-server-chosen",
       }
   ],
...

If the client also supports this optional extension and parses the
"alreadyHavePartially" section, the client may resume their upload by:

    1) verifying that digest of the client blob from byte 0 (incl) to
       "size" (exclusive) matches the server's provided "partBlobRef".
       (the server must use the same digest function).  if it doesn't,
       skip, and/or proceed to any other "alreadyHavePartially"
       blobref with the same "blobRef" value.  (the server may have
       multiple partial uploads in different states, and perhaps one
       is corrupt for various HTTP client failure reasons...)

    2) do an upload like normal, but the name of the
       multipart/form-data body part should be whatever the server
       provided in the mandatory "resumeKey" value.  skip the first
       "size" bytes in your upload.