New method matching algorithm introduces behavioral change wrt return types

[stakx]

Moq used to match return types of the invoked vs. expected method precisely:

https://github.com/moq/moq4/blob/271a12abdaa6edbe042e20d9984b8de64a4dad54/src/Moq/InvocationShape.cs#L108-L111

However, that is now no longer being done (as that check was removed in 1c1a934#diff-75ebcf2b80e95adb61d9a8500dfeb229L108-L111).

This is a task item for myself to figure out whether the old behavior should be brought back. I'll need to research old issues where we were already talking about this, and see what those use cases were, and judge how they will be affected by the new behavior.

Also, a changelog entry should be added if the new behavior stays.

[stakx]

In #552 (comment), I wrote:

When Moq looks for a setup matching the invocation, the invoked method's signature is compared with that of the set up method's [...]. Return types must match exactly[.]

And later:

[R]elaxing Moq's method matching logic would be wrong[.]

I can no longer remember what made me think so. I also haven't yet been able to think of a use case where that matching rule would be actually helpful—which is probably because method resolution in C# ignores return types completely. Moq should perhaps follow C#'s lead, thereby removing issues people have faced with setting up generic methods (see e.g. #343 (comment), #552 (comment), possibly #656).

[stakx]

Closed by #907.