fix: Standarize/disambiguate return from `Parse`

[nima]

problem: digest.Parse (prototype func Parse(string) (Digest, error)), returns the tuple (Digest, error). The expected behavior of a function in Golang that returns such, i.e., (Object, error), is that either returns (<something>, nil) (form A), or otherwise (<nothing>, <error>) (form B)--but not (<something>, <error>) (form C). This is, however, what this function does.

This is a very minor fix, since it is also expected that callers first pay attention to the error returned, before looking at the datum. And so, we can drop this PR if people deem it unnecessary. When I first made this change, it was because I came across a use case in oras-go where the caller ended up using the datum despite an error, which has now been corrected.

change: Make it return one of the two valid forms (forms A and B), and not the third (form C).

cc: @AkihiroSuda, @thaJeztah

supersedes: #76

[stevvooe]

While technically idiomatic, there are cases where you'd return something in the case of an error. Here, I don't think that would be validate. To users of the package, I would really recommend to always check error before using the return result.

However, since this would actually be a breaking change, I don't know that we should fix this.