Disable using Stringer/error interfaces for diffing

[luan]

NOTE: this changes something that is the default behavior. I intentionally am doing this as a proposal to change that behavior because I think the new one is better. If this is a problem, we could also achieve the goal of this PR by making spewConfig somewhat accessible so that the user of the library can choose to DisableMethods themselves.

spew's default formatter will call String() or Error() in structs
that implement the fmt.Stringer or error interfaces. Depending on
the implementation of those, the diff can become quite useless to read
(see the example struct I used for the test case in this commit).

This changes spew's configuration to DisableMethods so that it will
always use it's own pretty printer. This makes testing structs less
surprising and generally more useful, without tying the tests to the
implementation of String() (the user here can always choose to
require.Equal(a.String(), b.String()) if testing those is important to
them.

[boyan-soubachov]

I think this change makes sense but am I correct in thinking that we're now delegating our own test output format to spew's output format? Would this be wise?

Given that the result of our test assertions are definitely a key feature/purpose of this framework, would it make more sense to rather update our formatting output to match `spew's or, at the least, version-lock our spew dependency?

[luan]

@boyan-soubachov we were always delegating it to spew to be fair. This change merely makes us always delegate as opposed to only when the object being tested doesn't implement fmt.Stringer.

I think maintaining a formatter as part of testify would work. But given that we've been using spew for this for a while it feels like a much larger step.

I do agree with you that the failure messages that testify generates are a key part of the framework and we should find a way to make them as high quality and consistent as we can. So I agree with version locking. But isn't that already done in go.mod here?

[boyan-soubachov]

This looks good to me! 👍 Thank you for your contribution.

@glesica , would you like to give this PR a once-over?

[glesica]

Seems very reasonable to me. Thanks for the contribution!

[AlekSi]

See #989

[HaraldNordgren]

Fix: #1072

[marcel]

This should have exported the spew config to make this configurable, even if it changed the default. Proposing s.Equal(expected.String(), actual.String()) makes sense in the trivial case where you are comparing values directly but is very inconvenient when comparing slices, maps or any other composite data structure that contain types such as those based off of uints or bytes that are not human readable without a lot of cognitive work.