Support other multierr implementations

[abhinav]

We previously dropped support for integrating with error implementations which expose the underlying list of errors via some interface like,

type MultiError interface {
    Causes() []error
}
// Type and method name up for discussion

This issue is to discuss the possibility of adding something like that back and implementing that interface on the library's error type.

Besides integrating with other libraries, this will allow multierr to be compatible with other versions of the same library. That is, adding an interface like this will allow us to handle the case where one repo is using version A from foo/vendor/go.uber.org/multierr and another repo is using version B from bar/vendor/go.uber.org/multierr. Error types returned by version A will be compatible with Append calls in version B because they'll both implement the MultiError interface.

Implementation detail: We'll still want to keep the optimization where the error type matches *multiError exactly. We'll just add a fallback case for the interface-version which will be a bit slower.

[akshayjshah]

We can do this via the unexported errorGroup interface now, correct?

[abhinav]

Yeah, we can implement this with the errorGroup interface. We'll want to keep the existing fast path implementation where the error is a *multiError and add a slow copy-based path for errorGroups.