Ensure explicitly implemented members are discoverable in BeEquivalentTo - #2152

• When trying to find a property on the subject to match the one on the expectation, if a normal property exists next to an implicitly implemented one, the normal property will be selected.
• Some tests related to explicit interface implementations assumed a dependency on whether or not RespectingDeclaredTypes and RespectingRuntimeTypes was used. But those options don't affect the subject.
• The WithMapping construct also didn't support mapping to properties implemented through explicitly-implemented interfaces.
• Removed the "non-private" part names since visibility is now used to find members

Note I had to extend MemberVisibility to optionally include explicitly implemented members. This could be perceived as a breaking change. But it won't affect consumers, so for now, I treat it as non-breaking.

Review
Review by commit and with whitespace changes hidden

Fixes #2146

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