Leader VRF value no longer settling ties

I do not know whether or not we've found a bug or just discovered the consequences of an intentional decision.

---

The final tie breaker for "slot battles" is the leader VRF value:

https://github.com/input-output-hk/ouroboros-network/blob/9249a70ed9e2365f3963e47cb31b4b1589bca8f6/ouroboros-consensus-protocol/src/Ouroboros/Consensus/Protocol/Praos/Common.hs#L62-L68

In the `TPraos` protocol (used prior to the Vasil HF), `csvLeaderVRF` was the leader VRF value. In the `Praos` protocol, however, `csvLeaderVRF` is being set to the single VRF value in the block header (prior to the range extension).

**This removes a small advantage that small pools previously enjoyed.** Small pools are more likely to win this tie breaker, since by being a small pool they need a smaller leader VRF value in order to win the leader check. Using the the VRF value before the range extension is applied removes this small advantage.

---

The Evidence:

The view, `PraosChainSelectView`, is populated by the `BlockSupportsProtocol` class method `selectView`, which uses the `ProtocolHeaderSupportsProtocol` class method `pHeaderVRFValue` to set `csvLeaderVRF` in the view.

* In `TPraos`, `pHeaderVRFValue` uses the leader VRF value:
https://github.com/input-output-hk/ouroboros-network/blob/9249a70ed9e2365f3963e47cb31b4b1589bca8f6/ouroboros-consensus-shelley/src/Ouroboros/Consensus/Shelley/Protocol/TPraos.hs#L111
* In `Praos`, `pHeaderVRFValue` uses the raw header VRF value:
https://github.com/input-output-hk/ouroboros-network/blob/9249a70ed9e2365f3963e47cb31b4b1589bca8f6/ouroboros-consensus-shelley/src/Ouroboros/Consensus/Shelley/Protocol/Praos.hs#L141

---

This was discover here: https://github.com/cardano-community/cncli/issues/19