[docs] Clarify expected semantics of deflate compression (#36113)

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.

Closes #36113

COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36113 from akshayjshah:deflate 9177d39d63
PiperOrigin-RevId: 617635558

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