Add optional Content-Location response header

... to inform the Client about the permanent location of completed
uploads.

This is motivated by the following use cases:

* TUS servers may not implement storage themselves, such that the
  `Location` returned for a creation (POST) request be only
  transitional.

* TUS servers may decide to change the storage location once the upload
  is complete, for example to

  * implement content-based naming (where the file name is some hash
    over the content)

  * name content based on type

  * or select paths by size

The `Content-Location` header is already defined by the HTTP RFCs, so,
stricly speaking, its use should be implicitly allowed and well defined.
Yet, for TUS, it makes sense to allow use of this response header for
additional HTTP verbs (e.g. `PATCH`) and it might help implementation
interoperability to point it out.

Author: nigoroll

protocol.md

@@ -141,6 +141,7 @@ Tus-Resumable: 1.0.0
 HTTP/1.1 204 No Content
 Tus-Resumable: 1.0.0
 Upload-Offset: 100
+Content-Location: https://tus.example.org/storage/d41d8cd98f00b204e9800998ecf8427e
 ```
 
 ### Headers
@@ -191,6 +192,16 @@ interpreted as the request's method by the Server, if the header is presented.
 The actual method of the request MUST be ignored. The Client SHOULD use this
 header if its environment does not support the PATCH or DELETE methods.
 
+#### Content-Location
+
+The Server MAY send a `Content-Location` header with any response to a
+`POST`, `PATCH`, `HEAD` or `GET` request once the upload is complete
+(`Upload-Offset` == `Upload-Length`) to optionally indicate to the
+Client a new location of the upload.
+
+See [RFC 7231 Section
+3.1.4.2](https://httpwg.org/specs/rfc7231.html#header.content-location).
+
 ### Requests
 
 #### HEAD