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.