API error definition mechanism that is type-safe across runtime boundaries

At the moment, go-ipfs core implementation returns plain Go errors (often ad-hoc ones, creatde with fmt.Errorf), which forces all client (e.g. HTTP API clients) code to discriminate errors based on ad-hoc string and sub-string matching.

We would like to design a custom error type, which can facilitate (and make safe) error discrimination in two settings:
* when errors are returned as Go errors (i.e. when calling a Go API object directly), and
* when errors are returned as strings (or structures) over the wire (e.g. as in the HTTP API case)

The mechanism should support annotations and ideally stacking (wrapping) with source line info.

An example of where this problem occurs, when writing HTTP clients one is forced to do this:
https://github.com/ipfs/go-ipfs-http-client/pull/114/files#diff-95ad8db4f69eb5c860efd5d90d02d3d3R94