feat: add name and code fields to MultihashHasher interface

[achingbrain]

This appears to have been missed off, unless it's been done on purpose?

Makes MultihashHasher consistent with MultibaseEncoder, BlockEncoder, etc.

Also fixes a small typo.

[rvagg]

I'm not sure about the reason for the omission, code might be even more useful here. I'm suspecting a bias toward minimalism to give maximum composability. @Gozala will have to answer to that though.

This is fine by me unless @Gozala registers an objection.

[Gozala]

I'm not sure about the reason for the omission, code might be even more useful here. I'm suspecting a bias toward minimalism to give maximum composability. @Gozala will have to answer to that though.

fewer requirements on interface is easier to satisfy, so unless there’s a compelling reason (which didn’t exist in multiformats at a time) it’s best to keep things out until necessary. And if it’s necessary in 20% of cases maybe separate interface for those is a better option still

[achingbrain]

unless there’s a compelling reason

This will be useful to list configured hash algorithms in a way that is easily digestible for a human without consumers having to maintain their own lookup tables.

For example js-ipfs does this to list and validate which hash algorithms are supported on the cli and follows the same pattern to validate incoming http args and needs this PR in order to ultimately remove the dependencies on multihash*, multicodec, and multibase and use multiformats instead.

code might be even more useful here

Good point, this should also be in the interface, as it is with MultibaseEncoder and BlockEncoder. I've added this.

[rvagg]

As it so happens, these last couple of days I've run into precisely this problem with some HAMT code. We record the multihash code for the algorithm used to hash entries in the root of the structure and I'm typing the interfaces now and it accepts a MultihashHasher as your hash algorithm ... but I can't get code off the interface!
So I'm fine with this, I think it's reasonable and I see multiple usecases for it.