HaveBeenCalled(int) and HaveBeenCalledTimes(int) are duplicates of each other

## Problem

`RequestMockResponseBuilderAssertions` exposes two methods that do the same thing:

```csharp
public AndConstraint<...> HaveBeenCalled(int times, string because = "", params object[] becauseArgs);
public AndConstraint<...> HaveBeenCalledTimes(int expected, string because = "", params object[] becauseArgs);
```

Both validate the argument is non-negative, both compare `subject.RequestMock.InvocationCount` for exact equality, and both return the same constraint. The only difference is the failure wording:

- `HaveBeenCalled`: `"...but it was called {3} time(s)."`
- `HaveBeenCalledTimes`: `"...but it was invoked {3} time(s)."`

This looks like the result of the two parallel PRs that landed the per-mock invocation assertions (#32 and #36) both adding their own spelling.

## Why it matters

Two names for one concept is a discoverability tax: users have to wonder whether the difference is meaningful. It also means every future change (say, adding "at least"/"at most" semantics) has to be made twice.

## Proposal

Keep `HaveBeenCalled(int times)` — it reads better in a chain and pairs with the parameterless `HaveBeenCalled()` and with `NotHaveBeenCalled()`. Mark `HaveBeenCalledTimes` `[Obsolete]` pointing at it, and remove it in the next major.

Requires an `AcceptApiChanges.ps1` run for the approved-API files.

Start by locating RequestMockResponseBuilderAssertions and compare the two invocation assertion methods. Mark HaveBeenCalledTimes as obsolete in favor of HaveBeenCalled, then run AcceptApiChanges.ps1 and update the approved-API files. Done means the duplicate API is clearly deprecated and the approved API files reflect the change.

Written by the indexing model from the issue text.