IPFS: disambiguating API errors uses fragile string comparisons

[djdv]

Extracted from: #27 (comment)

This might get resolved in ipfs/go-ipld-format#76

I have to double check all the call sites to see if we still even receive errors from the core API.
resolveErrKind was written and errors were added when they were needed, but not removed during refactors.
Specifically, we first used core.Resolve{Path,Node} before switching to node.Resolve.
Which iirc is why there's 2 different sets of error checks.

This concern might get blasted away if we switch to a resolver.Resolver. (rel: #29)
But this is not yet clear. We'd have to see what values the resolver returns and if they're defined with Go 1.13 error conventions.

Other projects have encountered this same issue: https://github.com/ipfs/boxo/blob/0927be43c36cf7d1c557e65157cab9301b8a89f3/gateway/errors.go#L175