Test with `k = 1` in test-consensus

This Issue is a follow-up to Issue input-output-hk/ouroboros-network#1489.

While working on input-output-hk/ouroboros-network#1489 et al, it became clear that `PBFT` and `RealPBFT` should use more `k` values than just `5` or `10`. In particular, the recently added `DualPBFT` tests use other values, and fixing input-output-hk/ouroboros-network#1489 unmasked related bugs there.

My imminent PR for input-output-hk/ouroboros-network#1489 will resolve this for `k > 1`. But the `k = 1` case seems to be confounded in at least three ways. I don't want these to block a PR for input-output-hk/ouroboros-network#1489 -- hence this issue.

1. `prevPointAndBlockNo` ignores the anchor point of the current chain and falls all the way back to `genesisPoint` instead. I don't know why only `k = 1` seems to trigger this. The tests fail with `the first block on the Byron chain must be an EBB...`.
1. `Test.ThreadNet.Ref.PBFT.viable` and Byron's `anachronisticLedgerView` disagree on when `TooFarAhead` should be raised. In the `k = 1` case, "not viable" is "0 blocks in `2k` slots", which conceptually aligns with `TooFarAhead`. However, `TooFarAhead` uses `now + 2k` as an _exclusive_ upper bound. If I naively change it to _inclusive_ then I see no test failures of this kind. I doubt that's the right fix, however. The tests fail with `Missing or unexpected EBBs...`. (The net is stuck in a way the `Ref` simulator did not anticipate, so it's unable to produce anything, including the expected EBBs.)
1. In the `ProduceEBB` case, a `RealPBFT` node may produce two blocks during a single slot: an EBB and a subsequent proper block. With `k = 1`, this might introduce a wedge. The test fail with `after dropping X blocks from...` (i.e. there's too deep of a fork in the final chains). (Another node might be able to fit a proper block before that EBB --- I think this requires a node to restart and also lead in the new EBB's slot -- it'll forge the new EBB and its subsequent block before syncing the pre-EBB slot from the others? Something like that, I think.)

Edit: I think the `TooFarAhead` bullet is the same as Issue input-output-hk/ouroboros-network#1524. And I have a imminent fix for that (use strict inequality in `forkEbbProducer`).