dennisdoomen/fluentassertions — pull request #189 by vossad01 (2014-11-27 06:16:12+00:00)
Title: Starts to replace AssertionRules in favor of EquivalencySteps

This is groundwork for a lot of things but should not make any changes impacting users (other than `AssertionRule` being deprecated, though I do not know why anyone would use that directly). This is simpler than history might suggest, but I am sure it will need some discussion.

This is working to achieve a number of things. The first reason is what got me started on this, but it ties in with a number of other things that have crossed my mind from time to time.

1. Eventually deprecate and remove the `IAssertionRule` interface. It and `IEquivalencyStep` serve the same function but `IEquivalencyStep` is more robust, if one can be eliminated it will reduce duplication of effort in maintaining two similar interfaces. This duplication as a burden becomes apparent when trying to address Issue #22.
1. Ultimately expose a `Using` IEquivalencyStep to allow users/library designers to provide their own additions to the Equivalency pipeline. This could be things like a NodaTime step that better handles its types to mitigate things like Issue #15 or .NET types like in #134. Not sure if it will actually be used, but it could be powerful. Use of this extensibility will be more practical when there is central configuration as is coming out of #171.
1. Provide a way that configuration of the equivalence assertions can affect the root object. Arguably, it could be seen as an abuse of `ShouldBeEquivalentTo` to use it where you need to define custom assertion behavior on the root object; instead you should be using `Should`. However, given FA defines special behaviors for certain root object types with `ShouldBeEquivalentTo` I would imagine users could find value it as well and do not see the need to restrict it only to properties.
1. I could see value in also exposing the built-in steps in some fashion so they can be removed or reordered if desired by the user (ex. user never wants the conversion step), but I think it is premature to decide that is actually needed. I am thinking maybe something like a the situation in Issue #157 with wanting very different dictionary might start to point towards this flexibility.

This does not deprecate `IAssertionRule` yet or expose `IEquivalencyStep` because I think Issue #22 cause changes to some of the interfaces.

When debugging the Equivalence validation, this also makes it a little easier to follow the impact of custom configuration because there are no longer two levels of check (Assertion Rule and Equivalency Step).

The good news is I do not think I did anything with boolean expressions in this one, so I am probably no missing parenthesis in those again :)

This is based on #177, will either need to be rebased or merged after that one. Of course, let me know if there is something you want me to do.