Enable multihash support for swarm root hashes & ENS

[cobordism]

Goal: as described in #166 we want to be able to request swarm data using URLs of the form bzz://<multi-hash>/path/in/manifest.

The reason is that this will allow people to store multi-hashes in the ENS resolver contracts at "content" and thereby allowing swarm and ipfs and other systems to exists side by side.

This change also allows us to add to ENS Swarm content that has been uploaded with the --encrypt flag. In the current system that is not possible.

• Enable retrieval of swarm-content using a multi-hash in the URL
• Generate a multi-hash when uploading swarm content
• Document the functionality in the swarm docs
• Notify the ENS guys -> Need new resolver and new ENS tools.
• Update all our own ENS names to use a multi-hash

[gbalint]

Is this surely needed for 0.3?

[cobordism]

I bundled all the backward compatibility breaking changes under the 0.3 label.

[cobordism]

let's not change the hashes that go into ENS twice. Once for BMT and once more for multihash.

[gbalint]

Ok, I get it, let's not break compatibility again after 0.3 if possible

[cobordism]

I'll repeat my comment from Issue 440 - because the --encrypt flag is new.

With the advent of encrypted swarm uploads (swarm up --encrypt) requiring double length hashes, it is time to update swarm to use multi-hash.

Adding the double-length encrypted swarm hashes to ENS would require a lot of changes. According to Arachnid:
"Presently the return type for content hashes is 'bytes32'. Changing this would require writing a new resolver (ideally, after writing an EIP describing the new type). Existing tools that use the resolver (including manager.ens.domains) would need updating to support the new type."

And if we are already in need of changing so much, this is the perfect opportunity to:

"Instead of bytes32, we can use 'bytes', and start using multihash, so we can support Swarm, IPFS, and any other content-addressed system."