Provide way to assert completed calls without using Repeated class

As mentioned by @jholovacs in #808, the Repeated in A.CallTo(() => f.Boo()).MustHaveHappened(Repeated.Exactly.Once) could be construed as meaning “Boo must have happened, and then it must have been repeated, for a total of two calls”. After much discussion, we’ve resolved to provide alternative methods and eventually deprecate and remove Repeated. As noted in that issue, we’ll introduce the following API:

MustHaveHappened()    // as today
MustNotHaveHappened() // as today

MustHaveHappenedOnceExactly()
MustHaveHappenedOnceOrMore()
MustHaveHappenedOnceOrLess()

MustHaveHappenedTwiceExactly()
MustHaveHappenedTwiceOrMore()
MustHaveHappenedTwiceOrLess()

MustHaveHappened(3, Times.Exactly)
MustHaveHappened(3, Times.OrMore)
MustHaveHappened(3, Times.OrLess)

MustHaveHappenedANumberOfTimesMatching(n => n %2 == 0) // the argument is an Expression<Func<int, bool>>

Times is a new class.

This satisfies the following goals:

1. Eliminates the confusion over the exact semantics of Repeated
2. Retains MustHaveHappened() and MustNotHaveHappened(), which are the most popular methods in use today
3. Improves discoverability, even over the existing Repeated mechanism
4. Provides a consistent, natural word ordering (to contrast with Repeated.Times(3))
5. Does not require an extension method on int
6. Avoids forgettable terminal operators (e.g. MustHaveHappened(3).Times, where the Times could be forgotten)
7. Allows for a soft transition away from the current methods; the Repeated variants can live for a major release or two and be deprecated in 5.0.0 and removed in 6.0.0.

[blairconrad]

One concern I’d have with deprecating in 4.4.0 is that any consumers of the old API who have TreatWarningsAsErrors will find themselves unable to build when they pick up 4.4.0. This may be a bit of surprise for a minor release. Of course, one could say that they had it coming by turning on that flag…

[blairconrad]

@Mertsch, by all means guide people to the new APIs. I would. And we have an update to the Analyzer in the works that will also guide them as soon as it’s done.

The main reason we did not deprecate the APIs yet is that that can be considered a breaking change. It’s common in the OSS framework ecosystem^{citation needed} to deprecate an API in a major release and remove it in the following major release. Accordingly, we should deprecate in 5.0.0 and remove in 6.0.0. We don’t yet have any timing around a 5.0.0 release, but it is something we could investigate.