Add containsMatchingInOrder containsEqualInOrder

[natebosch]

The joined behavior in containsInOrder has some usability issues:

• It mimics the arguments for deepEquals, but it doesn't have the same behavior for collection typed elements. Checking that a nested collection is contained in order requires a Condition callback that uses .deepEquals explicitly.
• The Object? signature throws away inference on the Condition callback arguments. With a method that supports only conditions the argument type can be tightened and allow inference.

Deprecate the old containsInOrder and plan to remove it before stable. This is a bit more restrictive, but it's not too noisy to fit a few (it) => it.equals(foo) in a collection that needs mixed behavior and the collection of two methods is less confusing to document than the joined behavior.

Lean on the "Matches" verb for cases that check a Condition callback and rename pairwiseComparesTo as pairwiseMatches.

Fix a type check when pretty printing Condition callbacks. Match more than Condition<dynamic> by checking Condition<Never>.

[github-actions[bot]]

PR Health

Changelog Entry :heavy_check_mark:

| Package | Changed Files | | :--- | :--- | Changes to files need to be [accounted for](https://github.com/dart-lang/ecosystem/wiki/Changelog) in their respective changelogs.

Package publish validation :heavy_check_mark:

| Package | Version | Status | | :--- | ---: | :--- | | package:checks | 0.3.1-wip | WIP (no publish necessary) | | package:test | 1.25.9-wip | WIP (no publish necessary) | | package:test_api | 0.7.4-wip | WIP (no publish necessary) | | package:test_core | 0.6.6-wip | WIP (no publish necessary) | Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[natebosch]

2257 highlights another place where mixing the matches/equals behavior has a negative impact on the UX. There we are mitigating it by special casing arguments that don't use Condition in some places. I don't think that it makes sense to try to split between deepEquals and deepMatches in that case. The distinction comes down to the deep vs non-deep behavior. With the shallow "contains" check we get a bigger benefit from type inference on the condition callbacks (can allow typed Subject arguments, instead of Subject<dynamic>).