Remove the APIs for hashing and only do the encoding about rust-multihash

[bochaco]

I just tried to start using this crate and was having issues when decoding a CID, and I just figured the problem is exactly this, the multihash::encode is hashing my string rather than just prefixing it with hash-code and length, which I thought is what multihash specs defines, at least that's what I understood and saw happening with other implementations like JS that I've been using before, and I looked at Go impl which does the same, i.e. only encoding and no hashing.

[dignifiedquire]

I think you are right, having the hashing functions in here makes life much harder than necessary. I think having the following in this crate makes more sense

/// Owned hash.
pub struct Multihash(Hash, Vec<u8>);

/// Referenced version, more similar to what we have currently
pub struct MultihashRef<'a>(Hash, &'a [u8]);

With an api like this

use multihash::{Multihash, MultihashRef, HashTyp};

let hash: Vec<u8> = blake2b("hello world").into();
let mh = Multihash::new(HashTyp::Blake2b, hash).expect("invalid hash size");
let mh_ref = multihash::MultihashRef::new(HashTyp::Blake2b, &hash).expect("invalid hash size");

// Concats the code for the multihash prefix with the actual hash bytes
let mh_bytes: Vec<u8> = mh.to_vec();

[dignifiedquire]

Thinking about it some more, most of the code in #30 is good, as the new Multihash and MultihashRef in there are mostly working like what I described above. I think a future step is just splitting the encoding functionality either into its own crate or behind a feature flag.

[vmx]

With the introduction of multihash:wrap() the create can do both, hashing and multihash encoding.

If it turns out to be a problem, we could split it into two crates. But for now I'll keep it a single one, hence closing this issue.