Introducing Content-Digest in digest-headers

[Roberto Polli <[e-mail]>]

Dear folks,

since in the past meetings and on the list there was a demand for a
checksum mechanism
based on the actual data transferred on the wire (eg. the content) instead of
the representation data, with Lucas we decided to create a PR introducing the
`Content-Digest` field.

@Lucas Pardue  please feel free to integrate/clarify on everything.

Implementers that don't care about partial representation and just
want to implement
a checksum mechanism eg. in a reverse proxy, might prefer Content-Digest.
Implementers writing applications that need to verify the actual
application data
(e.g. the checksum of a  pdf file after resuming a download) might prefer using
Digest instead.

Both fields are independent from each other, so it is legit to use
both, though we don't know
whether it's worth mentioning that in the spec.

This is a preliminary PR that we want to present at tomorrow's meeting:
clearly it needs further work.

- https://github.com/httpwg/http-extensions/pull/1543/files

This new field, with the same syntax and algorithms of `Digest` is thus computed
on the actual content bits sent in the request or response. Here you
can see a brief list
of possibilities:

1. in the general case, eg. a simple GET, Digest and Content-Digest
will convey the same values.

2. When partial representations are conveyed (eg. range-requests),
Digest will contain
the checksum of the whole representation-data, while Content-Digest
will be computed
on the actual exchanged bits.

3. For HEAD responses, Digest will convey the checksum of the selected
representation data, while
Content-Digest, since there's no content, will convey the checksum of
an empty string.

FYI interim slides are here:
- https://docs.google.com/presentation/d/1W6Bc4G6OgkcMjuppOgjhynVF5wXsNG2RA2P_ZyMHYp4/edit#slide=id.gdc080ffd07_0_6

In the meantime, thanks to everyone for helping us in this long work,
R.