[Fixes #78561566] Separate and fix serve stale tests

#### Merge the two ServeStaleOriginDown tests

I split these into two tests in 7cce799 because we found that the behaviour
was different depending on whether you wait for the health check to expire
or not. The intention was to stop the tests failing and document the nuances
of the current behaviour.

In hindsight I think this was a mistake. They are confusing to read and make
it unclear what our *desired* behaviour is. If we're unable to get the right
implementation but we're confident about the test implementation then we
should use `t.Skip(notSupportedByVendor)` in the meantime, as we have done
for some other tests recently.

So merge them back into a single test for serving stale when origin is down.
We use `respTTLWithBuffer`, like the other stale test, to ensure that we're
well beyond the object's normal TTL. We do this before stopping the origin
to ensure that we're not relying on health check expiry.

The one difference now between the OriginDown and Origin5xx tests are that
the latter also checks that the stale object isn't used when origin comes
back. We might want to implement this for OriginDown later. But I suspect
that it may be complicated by removing `checkForSkipFailover()` from these
tests - which I'll explain in a following commit.

NB: The old test relied on `healthCheckExpire` to also ensure that we were
beyond the TTL. This was a mistake - it just happened that the expire time
was longer than the TTL.

#### Remove checkForSkipFailover() for TestServeStale*

Remove the `checkForSkipFailover()` check, which prevents a test from being
run if we don't have multiple backends, so that we can run the ServeStale
tests against CloudFlare who have implemented this but (not yet) multiple
backends.

These tests are now agnostic about how many backends exist in addition to
origin. If any exist, then we set their handler to assert a test error when
they receive a request.

This has surfaced the quirk that we were already aware of with our Varnish
serve-stale implementation. The test for OriginDown works if you run it with
`-skipFailover` because Varnish never successfully health checks the
additional backends and always considers them sick. But if you run it with
multiple backends then it doesn't serve stale on the first restart and hits
the first backup server on the second restart. I'll look at either fixing
this or temporarily skipping the test for that combination of arguments.

#### Fix serve stale in mocks by using fake backend

Fix `TestServeStaleOriginDown` when run against the mocks without
`-skipFailover`. This was failing - for the same reason that we split the
tests in 7cce799 - when origin is down and the health check hasn't noticed
yet then Varnish would:

- reattempt the request against origin on the first restart
- attempt the request against the backup server on the second restart
- invalidate the stale object with the response from the backup server

We can workaround this by using the "evil hack" described here:

- https://www.varnish-software.com/static/book/Saving_a_request.html#example-evil-backend-hack

It creates a new backend which will always be "sick"; never receives a real
request. It uses a port which shouldn't be bound on the guest, a request
that isn't valid HTTP, an interval that means it will rarely be polled, and
an initial value which means that it's immediately sick when Varnish first
starts.

This causes Varnish to use the stale/grace object (if it exists) on the
first restart and never invalidate it with a response from a backup server.
This now works the same regardless of whether `skipFailover` is or isn't
used.
Will there ever be a request after the second request given the `requestCount < 3` condition in the `for` loop? If not, this comment is misleading.