Move to expect from package:matcher

[natebosch]

• Delete test_api copy of the expect libraries and tests.
• Re-export package:matcher/expect.dart from test_api.
• Re-export from package:matcher/expect.dart directly to maintain the
  same library surface from package:test/test.dart and
  package:test/expect.dart.
• Remove some documentation about specific matchers from the README.
• Re-export some lib/src libraries that are used in libraries that we can't
  roll synchronously with this package.

Temporarily add dependency overrides on matcher while it is
unpublished.

[natebosch]

I'm going to rework this - we'll keep exporting the APIs from test_api for now so that we have a window to transition the export from flutter_test.

It looks like there are a bunch of other misuses of test_api in the flutter repo too, so we'll need to get that all cleaned up as we roll.

[natebosch]

This passed a presubmit, and I'm waiting on a global test run now. It should be possible to land in this state and start prepping for publish.

We will necessarily have to publish one of matcher or test_api with unsatisfiable constraints. There will be a cyclic dependency between these packages.
@jakemac53 @kevmoo - any concerns about a cyclic pub dep? We will be able to fix the cycle in the next release of test_api.

After publishing, I will work on cleaning up usage from flutter_test and other impacted uses of test_api by shifting them to using package:matcher/expect.dart.

[natebosch]

I didn't find anything internally that was using this import for any of these APIs.

[kevmoo]

I think a short-term cycle is fine. 🤷

[jakemac53]

As long as it isn't a library cycle I have no issue with a pub package cycle