Consider publishing a 1.0.0 release

[devoncarew]

This would not necessarily contain breaking changes; publishing 1.0.0 would just indicate the maturity and support of this package.

[devoncarew]

From a discussion, if we choose to rev. this to 1.0.0, doing this before package:checks is released would cause less work for the community (after that release, people will need an explicit dep on matcher in their pubspec in order to consume the package).

[natebosch]

We will want the 1.0 release to include expect, and AsyncMatcher and all the future/stream matchers, which are currently defined in package:test_api.

The next chunk of work is to move the definitions here, and re-export them in test from here instead of from test_api. We would remove the dependency on matcher from test_core and test_api.

The current sticking point is that tests of expect and especially expectAsync, rely on knowledge of the internals of the test runner for the runTestBody utility.

We work around this in checks currently but running in an error zone, and pumping the event queue to ensure the test ran and failed.

We might be able to use a similar pattern here for matcher, it is a little ugly, but I also don't know if it's ugly enough to justify new APIs in test_api for this use case.