Allow pre-gzipped inscription content

[janniks]

It could be interesting to allow inscription content which is already gzipped. This will be very useful for recursive inscriptions motivating inscribing smaller contents which can be referenced.

To be more precise ordinal content explorers/APIs should automatically set the content-encoding: gzip (and not re-gzip the content) if the mime_type of an inscription is application/gzip, application/zlib, or ...+gzip (e.g. image/png+gzip).

The +gzip suffix is not part of a ratified RFC, but has been proposed in a few and is commonly used.

References:

• RFC 6713: The 'application/zlib' and 'application/gzip' Media Types
• Proposed RFC 8460: +gzip Media Type Suffix
• Proposed RFC 9399: Image Formats

[Psifour]

The correct solution for content-encoding is a bit more complex. While gzip is incredibly useful it would instead be better to expose a new op code (2 or 4) that allows setting the content-encoding in much the same way we already set the mime-type with OP_PUSH 1.

[ciphrd]

Strongly agree with this point, imo Content-Encoding should, along Content-Type, be a part of the op codes supported by the protocol. Explorers could blindly forward this header in responses, browsers would naturally support it.