add ComparingByMembers(Func<Type, bool> predicate) to SelfReferenceEq…

[ursenzler]

…uivalencyAssertionOptions

Adds ComparingByMembers(Func<Type, bool> predicate) to SelfReferenceEquivalencyAssertionOptions<TSelf> so that it is possible to define the strategy used for comparison with a callback. This simplifies scenarios when a group of types should be handled differently than FluentAssertion's standard behaviour.

This is useful when for example structurally comparing F# record types that contain C# classes that do not implement equality.
F# records are by default treated as value types because they implement equality. As a result, the containing values are treated as value types, making structural comparison of the inner C# objects difficult (every type would have to be configured).
With the new callback, it is possible to define the behaviour for all record types at once:

actual.Should()
      .BeEquivalentTo(expected,
                      Func<_, _>(fun (config : EquivalencyAssertionOptions<'a>) ->
                          config.ComparingByMembers(fun t -> FSharpType.IsRecord t)),
                      "",
                      [])

IMPORTANT

• The code complies with the Coding Guidelines for C#.
• The changes are covered by a new or existing set of unit tests which follow the Arrange-Act-Assert syntax such as is used in this example.
• If the contribution adds a feature or fixes a bug, please update the release notes, which are published on the website.
• If the contribution changes the public API the changes needs to be included by running AcceptApiChanges.ps1/AcceptApiChanges.sh.
• If the contribution affects the documentation, please include your changes in this pull request so the documentation will appear on the website.

[dennisdoomen]

Would you be willing to also update the release notes and documentation as listed in the PR template? Otherwise we have to pick up the PR ourselves.

[dennisdoomen]

❌ Please document this new member in the same style as the other overloads.

[dennisdoomen]

🙃 I'm nitpicking here, but we prefer to keep those test names functional and never refer to the literal name of an identifier, e.g. When_none_of_the_members_should_be_compared_by_members_it_should_succeed

[dennisdoomen]

🤔 So is there some implicit or explicit order? Would be nice to capture that in a functional test name.

[ursenzler]

I close this PR because the change how ComparingByMember<object> handles basic types solves the same problem.