This pull request includes several important changes to improve the consistency and accuracy of member path handling in the FluentAssertions library. The changes focus on replacing the use of Name and PathAndName with Subject and Expectation properties in various classes and methods.

Member Path Handling Improvements:

• Src/FluentAssertions/Common/MemberPath.cs: Changed the constructor to use member.Expectation.Name instead of member.Name.
• Src/FluentAssertions/Common/TypeExtensions.cs: Updated the IsEquivalentTo method to compare property.Expectation.Name with otherProperty.Expectation.Name instead of property.Name.

Consistency in Node Handling:

• Src/FluentAssertions/Equivalency/Node.cs: Replaced Path and PathAndName with Subject and Expectation properties. Added the AdjustForRemappedSubject method to handle remapped subject members during structural equivalency checks. [1] [2] [3] [4]
• Src/FluentAssertions/Equivalency/INode.cs: Removed Name, Path, PathAndName, and Description properties. Added Subject and Expectation properties. [1] [2] [3] [4]

Adjustments in Equivalency Validation:

• Src/FluentAssertions/Equivalency/EquivalencyValidationContext.cs: Updated IsCyclicReference and ToString methods to use CurrentNode.Subject.PathAndName instead of CurrentNode.PathAndName.
• Src/FluentAssertions/Equivalency/AssertionChainExtensions.cs: Modified the For method to use context.CurrentNode.Subject.Description instead of context.CurrentNode.Description.

Updates in Matching Rules:

• Src/FluentAssertions/Equivalency/Matching/MappedMemberMatchingRule.cs: Changed the Match method to compare expectedMember.Subject.Name with expectationMemberName instead of expectedMember.Name.
• Src/FluentAssertions/Equivalency/Matching/MustMatchByNameRule.cs: Updated the Match method to use expectedMember.Subject.Name instead of expectedMember.Name. [1] [2] [3]

These changes collectively enhance the handling of member paths and improve the overall consistency and accuracy of the FluentAssertions library.

Closes #2812

IMPORTANT

• If the PR touches the public API, the changes have been approved in a separate issue with the "api-approved" label.
• The code complies with the Coding Guidelines for C#.
• The changes are covered by unit tests which follow the Arrange-Act-Assert syntax and the naming conventions such as is used in these tests.
• If the PR adds a feature or fixes a bug, please update the release notes with a functional description that explains what the change means to consumers of this library, which are published on the website.
• If the PR changes the public API the changes needs to be included by running AcceptApiChanges.ps1 or AcceptApiChanges.sh.
• If the PR affects the documentation, please include your changes in this pull request so the documentation will appear on the website.
  • Please also run ./build.sh --target spellcheck or .\build.ps1 --target spellcheck before pushing and check the good outcome