Fluentassertions: Treat types that override `Equals` as having value semantics

[dennisdoomen]

Dogfooding 5.0 has revealed some inconsistent behavior of how Should().BeEquivalenTo should deal with value vs structural comparisons. This is currently governed by https://github.com/fluentassertions/fluentassertions/blob/release-5.0/Src/FluentAssertions/AssertionOptions.cs#L36 and https://github.com/fluentassertions/fluentassertions/blob/release-5.0/Src/FluentAssertions/Equivalency/ValueTypeEquivalencyStep.cs. I can think of two options that could fix this:

1. Detect that an object overrides Equals and assume value semantics for that type. Add a method ComparingByMembers<T> (to counter ComparingByValue<T>) to override this behavior. Since we want to use anonymous types as an expectation, we should not treat those as value types.
2. Allow objects to be annotated with an attribute which name and namespace should match [FluentAssertions.HasValueSemantics] (by name, not by type)

Any opinions?

[mpopdam]

I don't like the annotation option.

[ronaldkroon]

Agree, I also don't like to add annotations to production code, just for the specs.
I really feel that if you implement Equals yourself that we should trust that it is indeed equal.

[dennisdoomen]

Solved in #740