Since the `ExecutionPoint` already stores the full backtrace, we should
already have it in the format for the relevant Ruby version. Using this
is a lot simpler than having to generate the line from scratch.

Since the `Expectation` instance already "knows" where it was defined,
it's simpler to use `Expectation#definition_location` to make these
assertions. And again, since this is obtained directly from the
backtrace, it should be in the format for the relevant Ruby version.

…ertions

Simplify backtrace-related assertions

This was added in this commit [1] as part of #633, but was never used. I
suspect it was accidentally left over after I changed my mind and added
the optional `ignoring_order` keyword argument to
`ExpectationList#match`.

[1]: 0800c6f

I'm about to make some changes in this area and this will make it easier
to see what's going on.

I'm planning to use this in a subsequent commit.

I'm planning to use this in a subsequent commit.

I'm planning to use this in a subsequent commit.

Currently when an invocation matches an expectation which does not allow
invocations (i.e. `Expectation#never` has been called on it), but the
invocation also matches another expectation which does allow
invocations, then the test does not fail with an unexpected invocation
error.

In #679 I'm planning to change this behaviour so the test fails fast
with an unexpected invocation error. This commit displays a deprecation
warning instead to give users a chance to update their code before the
actual change is made.

The new behaviour will bring the behaviour into line with what is
already the case for mocks where `Mock#stub_everything` has been called
as per this acceptance test [1] that was introduced in this commit [2].

[1]: https://github.com/freerange/mocha/blob/f2fa99197f35e2d2ce9554db63f6964057e29ce0/test/acceptance/expected_invocation_count_test.rb#L202-L214
[2]: d358377

In the previous commit, the changes meant that a block provided to
`Expectation#with` was being invoked three times instead of once. The
original behaviour was not explicitly documented and there is code in
the wild [1] that relies on `Expectation#with` only being called once
per invocation.

I'm not convinced that test code should be relying on this behaviour,
but from a performance point-of-view, it probably makes sense to avoid
calling the matching methods on `ExpectationList` multiple times
unnecessarily. This commit changes the code in `Mock#handle_method_call`
to avoid unnecessary calls to these methods.

I've created #682 to suggest improving the docs for `Expectation#with`
when it takes a block argument to address the ambiguity that has become
apparent.

[1]: #681 (comment)

…lity-should-display-deprecation-warning

Expectation with never cardinality should display deprecation warning