Move Matcher implementations to separate package

[seaneagan]

This package (matcher) could simply define the interfaces and default implementation.
It would be very easy to get such a package to stabilize to 1.0.0 and keep it there.
The test package and other packages which want to define a Matcher based API, such as constrain, would depend on matcher.

The Matcher implementations currently in this package could be moved to a separate matchers package which contains all the Matcher implementations which are currently in matcher, and it would be what users of test and other Matcher-based APIs would import. That would give the freedom to continue making breaking changes to these implementations, without it being a big deal, since it's only depended on by essentially end users.

This package could re-export the matchers package for a period of time, but that re-export would be deprecated. Is it possible to mark an export as deprecated?

@deprecated
export package:matchers/matchers.dart;

[seaneagan]

Filed a bug for deprecated exports.

[nex3]

I don't think this would provide a huge amount of benefit. matcher very rarely has breaking changes, and when it does they're usually tightly coupled to breaking changes in unittest anyway. Not only that, most of the uses of matcher through unittest are as leaf nodes on the package graph, and there aren't any plans to release breaking changes for a long time after unittest and matcher 1.0.0.