Support wrapped errors

[ansd]

This PR is a suggestion how to assert wrapped errors (see #334).

It covers two related but different use cases:

1. Test whether an error wraps another error.
2. Test whether an error wraps another error of a specific type.

Instead of having separate matchers for wrapped errors, the existing MatchError matcher is extended to test for errors.Is() and errors.As().

Rationale:
I think it makes sense to really test against errors.Is() and errors.As() instead of "only" testing for wrapped errors as a WrapError matcher would do since Is() and As() can return true although there are no wrapped errors at all.

I also think that it makes sense to test errors.Is() within the existing MatchError matcher instead of having an additional matcher which would be named like BeError since it would sound confusing to the user what the difference is between MatchError and BeError.

(One possibility is to extract the test for errors.As() into a separate matcher which would be named something like WrapOrBeAssignableToTypeOf. However, this also doesn't sound very clear.)

[blgm]

Thanks for this PR. I do like the fact that the MatchError() matcher that everyone knows about is now more powerful. The concern I have in the back of my mind is that it's a change of behaviour, so you can engineer a test that passes with the current version of Gomega but would fail with this change. Maybe that's such an obscure edge case that no-one cares? Maybe we should bump to a new major version just to be sure. These are the thoughts going on in my mind, and I'm wondering whether anyone else has thoughts or opinions?

[ansd]

Thank you @blgm for reviewing this PR.

I haven't thought about this before, but you're right that the behaviour changes.

The only case I can think of where a test that passes with the current version of Gomega but would fail with this change would look like:

Expect(ACTUAL).To(Not(MatchError(EXPECTED)))
where ACTUAL error wraps EXPECTED error

It's correct to say that this is a breaking change, but due to being a real edge case I personally wouldn't bump the major version.

[blgm]

@ansd, you have convinced me, so I'm going to merge this change. Thank you for your contribution!