Gateway: dynamic image for social sharing

We've added a basic social sharing markup in https://github.com/ipfs/dir-index-html/pull/36#issuecomment-647819924 :

> [](https://github.com/ipfs/dir-index-html/pull/36#issuecomment-647819924)

@lanzafame pointed me at [this nice prior art from Github](https://github.blog/2021-06-22-framework-building-open-graph-images/) shows how UX can be improved by showing useful data via image:

> [](https://github.blog/2021-06-22-framework-building-open-graph-images)

In IPFS context, a cool improvement would be to provide image-per-CID with:
- QR code with shareable URL that could be scanned via phone
- prior art: share.ipfs.io has nice IPFS-branded QR codes (https://github.com/ipfs-shipyard/ipfs-share-files/pull/119), we could do something similar
- I like the idea of having a branded QR code, as it looks interesting even when not consumed.
> 
> **QR code playground:** https://zpao.github.io/qrcode.react/
> URL of the icon: https://share.ipfs.io/favicon-32x32.png
- CID breakdown (codec, hash)
- dag-pb stats (total size, number of blocks)

Hot take:
- If we implement image generation as an alternative response format named `share-img` (as in, gateway response changing based on parameter `?format=json|cbor|car|block|share-img`) then we don't need to inline the data and don't need to deal with relative vs absolute vs cross-origin links (making this work on all gateway types without any additional configuration).

Start by reviewing Kubo's HTTP gateway response-format handling and the linked dir-index-html and ipfs-share prior art. The proposal describes a new share-img format containing a QR code, CID details, and dag-pb statistics, but names no files or tests. Done would require an agreed design and a working image response with coverage for its supported data.

Written by the indexing model from the issue text.