Further Simplifying the Response in Patch Subset

I've recently become aware of a proposal by Yoav to add a generic
compressed dictionary transport for http requests, see:
https://github.com/yoavweiss/compression-dictionary-transport

Conceptually the proposed static resources flow
<https://github.com/yoavweiss/compression-dictionary-transport#static-resources-flow>
is
quite close to how patch subset incremental transfer works. In brief this
proposes that:

   - A http request could include a new header which includes a value that
   identifies which version of a resource the client already has.
   - Then the response can use a new content-encoding (eg. brotli shared
   dictionary compression) which uses the clients existing copy of the
   resource during decompression.

This got me thinking that it may be a good idea to try and align patch
subset incremental transfer with how this works. Fortunately, we are not
very far off. Only two changes would be needed:

   1. Eliminate the PatchResponse message and instead have server send back
   a brotli or vcdiff compressed diff directly.
   2. Eliminate the accept_patch_format and patch_format mechanism in
   favour of using http "content-encoding"/"accept-encoding".

Overall, this builds on the previous work to move client state into the
font and further simplifies the protocol without sacrificing any
functionality. Here's a more detailed look at what would change:

*How to handle what's currently in patch response*

   -

   Protocol Version
   -

      Can be dropped, currently it's just hardcoded to “0”.
      -

   Patch Format
   -

      Use the content-encoding header instead.
      -

   Patch, Replacement
   -

      The response becomes the patch. The patch vs replacement distinction
      isn’t actually needed as encoders can easily generate a patch
which ignores
      the existing dictionary. Alternatively it can opt to use just regular
      brotli content encoding (or another encoding) for the replacement case.
      -

   Unrecognized Ordering - there are two options:
   - Use a http status code to signal this case.
      - Or specify fallback behaviour where the server sends the whole font
      if the ordering is unrecognized (if we expect this case is rare).


*Specification Changes*

   1.

   Drop PatchResponse message specification.
   2.

   In PatchRequest drop:
   1.

      protocol_version
      2.

      Accept_patch_format
      3.

   In “Handling Server Response” update to instead just treat the response
   as a patch using the specified content encoding. The “IFT “ magic number is
   no longer needed as content-encoding will signal if this is a patch or just
   a full file.
   1.

      Presence of the client state table in the font signals whether or not
      there are unrequested codepoints in the family.
      2.

      Add handling of the unrecognized ordering status code (if we choose
      this route).
      4.

   Update the "load a font in a user agent with an http cache" section as
   needed.
   5.

   "Responding to PatchRequest":
   1.

      Update to have the response just be the patch.
      2.

      Optional: for error handling server can just respond with the full
      font if it can’t successfully decode the request.
      6.

   Patch Formats section updated to instead specify the
   accept-encoding/content-encoding values to use for brotli and vcdiff.
   7.

   IFT Method Selection: updates may be needed here if it references the
   four byte magic number.