Feature Request: Add support for recursive checking of inner exception

Description

Sometimes, when writing high-level tests, we expect a function to throw an exception with a deeply nested inner exception. Writing assertions can be tedious if we only care about the existence of a certain type in the chain and not how deep it is located.

So in short, I would like to write something like this:

action.Should().Throw<ExceptionA>()
    .WithInnerException<ExceptionB>(recursive: true);

instead of:

action.Should().Throw<ExceptionA>()
    .Which.InnerException.InnerException.InnerException.BeOfType<ExceptionB>();

[dennisdoomen]

I think that’s a great idea and I would prefer WhoseInnerExceptionChain to emphasize that that it exposes not just the direct inner exceptions.

[julealgon]

Another possibility for this would be to convert it into a normal collection assertion with something like:

action.Should().Throw<ExceptionA>().WhoseInnerExceptionChain.Should().Contain<ExceptionB>();

This would be similar to the WhoseValue used in places like dictionaries and leverage all the collection assertions that already exist on top of the flattened list of exceptions (that could also be empty). It could also be a computed IEnumerable (i.e. deferred execution), depending on how we want to go about it.

I think the “Chain” wording at the end makes sense, but perhaps there is a better way to put it (perhaps just WhoseInnerExceptions, even though that could be a bit misleading when dealing with an AggregateException).

From what I’m seeing in the docs, it seems we don’t have a generic Contain<T> assertion, so I’d probably add that as well to make this work, since it would be a valid assertion to have for normal collections too (would be useful for polymorphic collections). Naming could either be Contain<T>, or maybe a more explicit ContainItemOfType<T> to go along the other “Contain…Items…” methods. While we are at it, a “Single” version should also be added to match.