Sharding support in /ipns/<fqdn> paths

[lidel]

This issue is extracted from #19 where @achingbrain simplified code by delegating sharding support to ipfs.files.stat

Context

• Wikipedia does not work when loaded via /ipns/<fqdn> due to lack of IPNS/DNSLink/HAMT support
  • Test path: /ipns/tr.wikipedia-on-ipfs.org/wiki/Anasayfa.html
• IPNS Support improvements (including DNSLink) are coming to JS IPFS
  • @hugomrdias leads this work in IPNS over DNS js-ipfs#2000
• feat: load files/dirs from hamt shards #19 fixes HAMT for/ipfs/ paths

Problem

• HAMT fix from feat: load files/dirs from hamt shards #19 is using ipfs.files.stat, which does not support /ipns/ paths atm.
  • ipfs files stat in go-ipfs also does not support them, so it is not a bug, just the way API works right now :)

Fix

If we reuse ipfs.files.stat for HAMT support in ipfs-http-response, and want to support IPNS as well, then js-ipfs-http-response resolver needs to convert /ipns/ paths to immutable /ipfs/ before passing them to ipfs.files.stat

Note: DNSLink-aware ipfs.name.resolve(path, {recursive: true}) is being added in ipfs/js-ipfs#2002, so this issue needs to wait for that to land first.

Rationale

Why do the IPNS resolve in ipfs-http-response and not in code using the lib?

• "batteries included", support /ipfs/ and /ipns/
• code deduplication between js-ipfs and other apps that use js-ipfs-http-response
• js-ipfs-http-response is responsible for rendering directory listing, and we want to be aware of both mutable and immutable pointer when creating the listing to display both