Gateway: support immutable fallback parameter on /ipns/ paths

## Idea
We could make sharing of mutable links (`/ipns/` namespace) more robust by adding support for a `fallback` CID:

https://ipfs.io/ipns/en.wikipedia-on-ipfs.org/wiki/Block_of_Wikipedia_in_Turkey?fallback=bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze

If IPNS ID or DNSLink name can't be resolved or fetched, gateway would return a redirect to the same resource under a content root passed via `fallback` :

https://ipfs.io/ipns/en.wikipedia-on-ipfs.org/wiki/Block_of_Wikipedia_in_Turkey?fallback=bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze → https://dweb.link/ipfs/bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze/wiki/Block_of_Wikipedia_in_Turkey

### Open questions

- should this be strictly only a CID, or does it make sense to allow arbitrary content paths like we do in DNSLink?
- CID is easier to reason about (content root), and implement (swap content root, nothing more)
- add support for `timeout` parameter that allows user to fallback faster?
- if we have this, fallback could be executed not only when IPNS or DNSLink can't be resolved, but also when resolved CID was not found in provided time budget (eg. due to missing provider)
- should user agents like ipfs-companion or brave append resolved CID as a fallback when copying Shareable link?