[checks] Add CheckFailure.describeNested - #2793

A failure from `check` throws as soon as an expectation is rejected, so the
failure details only describe the expectations up to the failing one. A
soft check keeps going after a rejection, and an unawaited expectation can
fail after later expectations were made, so in those cases the later clauses
were already added to the subject. `_fullDetails` described them along with
the actual value, as if the value satisfied them:

    check([Foo('foo')]).every(.it()
      ..field.startsWith('f')
      ..field.equals('bar')
      ..field.length.equals(999));

    Which: has an element at index 0 that:
        has field: a string starting with 'f'
        has field: 'foo'
        has field that has length: <999>
        Which: differs at offset 0:

When the failing clause came first, the later clauses also printed as
children of the actual which had collapsed onto one line:

      Actual: has value: <123>
        has value: <5>
      Which: is not equal

Only describe the clauses up to and including the one on the path to the
failure, both when collapsing and when describing the full structure. The
examples above now end at `has field: 'foo'`, and collapse to
`Actual: has value: <123>`.

An asynchronous nested expectation, such as `completes`, only adds its
clause once its value is available. An expectation made after it on the
same subject, which runs while it waits, is added first, so it is still
described, ahead of the failing clause.

An asynchronous nested expectation, such as `completes`, only added its
clause once its value was available. An expectation made after it on the
same subject runs while it waits, so its clause was added first. When the
asynchronous expectation then failed, the later expectation was described
ahead of it, and since it came first in the list it was kept by the change
to omit clauses after the failure:

    final subject = check(Future.value(1));
    final completion = subject.completes(.it()..equals(2));
    subject.has((f) => 0, 'zero').equals(0);
    await completion;

    Expected: a Future<int> that:
      has zero: <0>
      completes to <2>

Add a placeholder clause when the asynchronous expectation is made, and
replace it with the nested subject, or with the failing expectation, once
the value is available. Expectations made in the meantime come after it, so
they are omitted when it fails, the same as a failure from a synchronous
expectation:

    Expected: a Future<int> that completes to <2>
    Actual: a Future<int> that completes to <1>
    Which: is not equal

A placeholder is not described, so a later expectation which fails while
the asynchronous expectation is still waiting is described without it, as
before.

An expectation from `Context.expectAsync` added its clause as soon as it
was made, before its predicate had finished. When a later nested
expectation failed while the predicate was still running, the unfinished
expectation was listed under `Actual:` as if the value satisfied it.

`expectAsync` now adds a `_PendingClause` placeholder, the same one used
by `nestAsync`, and replaces it with the expectation once the predicate
finishes. The placeholder keeps the place of the expectation in the order
the expectations were made, and is never described, so a failure before
the predicate finishes leaves the unfinished expectation out. For example
with an expectation from `expectAsync` that has not finished followed by
`has((v) => v, 'self').equals(1)` on `0`, the failure now reads:

    Expected: a int that has self: <1>
    Actual: a int that has self: <0>
    Which: is not equal

Expectations from `Context.expectUnawaited`, such as `doesNotComplete`,
are left as they are. They are never awaited by the check, so they are
described as satisfied until they fail.

When an element of the expected collection is a `Condition` and the
actual element fails it, `deepEquals` formatted the failure by hand from
the `FailureDetail` and `Rejection`. That output lost the property the
rejection was for when the failure collapsed, repeated the value that
was already described when it didn't, and used `which` in place of
`Which:`.

Use `CheckFailure.describeNested`, the same as `IterableChecks.every`.
For example, with `['abc']` against
`[Condition.it<dynamic>()..isA<String>().length.equals(2)]`, the which
was:

    has an element at [<0>] that:
      Actual: <3>
      which is not equal

and is now:

    has an element at [<0>] that:
      Actual: has length: <3>
      Which: is not equal

When the condition doesn't collapse, the `Actual: <3>` line that repeated
`has length: <3>` is gone. The deeper indentation and the missing
`Actual:` prefix in that form are the same as for `every`, and are left
for a separate change.

When a soft checked failure doesn't collapse to a single line,
`describeNested` dropped the line for the root label, which was the only
line with `Actual:`. The remaining lines were indented 4 spaces under
the caller's line, where a collapsed failure is indented 2, and nothing
marked where the description of the actual value started. In
`pairwiseMatches`, which describes the condition first, the expected and
actual descriptions ran together:

    does not have an element at index 0 that:
      has field: 'foo'
      has field that has length: <4>
        has field: 'foo'
        has field that has length: <3>
        Which: is not equal

Replace the root label line with a line containing only `Actual:`, in
the place of the `Actual: <label> that:` line in a failure message from
`check`:

    does not have an element at index 0 that:
      has field: 'foo'
      has field that has length: <4>
      Actual:
        has field: 'foo'
        has field that has length: <3>
        Which: is not equal

Every nested failure now has an `Actual:` line, as the CHANGELOG already
says.

`FailureDetail` had a public constructor and a private one. The public
constructor recorded that a custom `actual` started with the line for the
root label, so `describeNested` dropped the first line of an `actual`
passed to it:

    final failure = CheckFailure(
      Rejection(actual: ['<3>'], which: ['is more than 2']),
      () => FailureDetail(
        ['a Box that:', '  has size: less than <2>'],
        1,
        0,
        actual: ['has size: <3>'],
      ),
    );

described the failure as only `Which: is more than 2`.

Nothing outside the package needs to construct either class. `Condition`
and `Context` are `abstract final`, so a failure only comes from soft
checking a `Condition`, and no API accepts a `CheckFailure` or
`FailureDetail` as an argument. All uses of the constructors are in
`checks.dart`.

Make the `CheckFailure` constructor private, and merge the two
`FailureDetail` constructors into one private constructor which takes
`collapsedDetails`, `actual`, and `actualHasLabel`. The classes are still
exported from `package:checks/context.dart` so a failure can be read.