Clarify expected semantics of deflate compression

I was surprised to see that the C++ core interprets
"grpc-accept-encoding: deflate" like HTTP: it compresses messages using
zlib with deflate compression, rather than using raw deflate. Matching
HTTP semantics makes sense, of course, but this misnomer has
historically confused HTTP implementations too.

This detail didn't seem important enough to warrant inclusion in the
main protocol specification, so I've proposed an addition to
`docs/compression.md` to document the expected behavior. I'm happy to
move the addition around if you'd prefer it elsewhere.

doc/compression.md

@@ -90,6 +90,15 @@ The inheritance of the compression configuration by child RPCs is left up to the
 implementation. Note that in the absence of changes to the parent channel, its
 configuration will be used.
 
+### Deflate Compression
+
+Like HTTP implementations, gRPC implementations MUST use the "deflate"
+compression to mean the zlib structure (defined in 
+[RFC 1950](https://datatracker.ietf.org/doc/html/rfc1950))
+with the deflate compression algorithm (defined in 
+[RFC 1951](https://datatracker.ietf.org/doc/html/rfc1951)).
+Servers and clients MUST NOT send raw deflate data.
+
 ### Test cases
 
 1. When a compression level is not specified for either the channel or the