Add equivalent to xUnit's Assert.Collection

Description

xUnit has this:

Assert.Collection(things,
    thing =>
    {
        thing.Id.Should().Be(guid1);
        thing.Name.Should().Be("Thing1");
        thing.Attributes.Should().NotBeNull();
        thing.FullName.Should().MatchRegex("^Thing1 [^ ]+$");
    },
    thing =>
    {
        thing.Id.Should().Be(guid2);
        thing.Name.Should().Be("Thing2");
        thing.Attributes.Should().NotBeNull();
        thing.FullName.Should().MatchRegex("^Thing2 [^ ]+$");
    });

In some situations I find this style more expressive and/or succinct than the FluentAssertions methods that assert collection equality or equivalence.

Assert.Collection signature:

/// <summary>
/// Verifies that a collection contains exactly a given number of elements, which meet
/// the criteria provided by the element inspectors.
/// </summary>
/// <typeparam name="T">The type of the object to be verified</typeparam>
/// <param name="collection">The collection to be inspected</param>
/// <param name="elementInspectors">The element inspectors, which inspect each element in turn. The
/// total number of element inspectors must exactly match the number of elements in the collection.</param>
public static void Collection<T>(IEnumerable<T> collection, params Action<T>[] elementInspectors)

Proposed API

Per https://fluentassertions.slack.com/archives/C039Y2H7U/p1527880297000421

things.Should().SatisfyRespectively(thing => { ... }, thing => { ... });

[jnyrup]

On the surface having these two overloads looks good as they both work on Action<T>:

• (params Action<T>[] inspectors)
• (IEnumerable<Action<T>> inspectors, string because, params string[] becauseArgs)

We already do that approach for several assertions: ContainKeys, NotContainKeys, ContainValues, NotContainValues, and more.

For some context/related issues, where params has caused issues.

• params object[] overload for BeEquivalentTo, #1036
• Not having because and becauseArgs parameters #806

[ishimko]

@jnyrup @dennisdoomen Can it be two overloads: one with IEnumerable<Action<T>> inspectors with because and args, and another one with params Action<T>[] inspectors without custom because?

Another option is to use builder for specifying inspectors with single “because” at the end. Something like

things.Should().SatisfyRespectively()
   .Thing(first => { ... })
   .Thing(second => { ... })
   .Becasue("there is such a feature in xUnit");

Although it is slightly different mechanism especially because of specifying “Because” at the end…