Improve transaction selection in case of collision

If two leaders are elected for the same slot, we _could_ get the block from the other node before we manage to produce ours. When this happens, we should create a fork, connecting our new block to the
_previous_ block, rather than appending it to the block we received.

This has a few consequences:

* When we applied the incoming block, we will likely have removed some transactions from our mempool, and so we will not include them in our own block.

This will be mitigated to some degree by the thread that monitors the chain and reintroduces transactions that get removed by a switch-to-fork (https://github.com/input-output-hk/ouroboros-consensus/issues/674).

However, even with that in place, we might still want to consider doing something special here. As it stands, that thread would notice some transactions got lost _after_ we produce our block, so that they might be included in the _next_. Ideally however we would include them in _this_ block.

Note that from the perspective of other nodes, the situation is slightly different. They will either adopt the block produced by the other node, in which case anything we decide to do is irrelevant, or they will produce the block that we produce, in which case any transactions that may be missing will probably still exist in their mempool (assuming that all transactions are sent to all core nodes).

* A related problem is that the mempool can contain dependent transactions. After applying the incoming block, the mempool might now contain transactions that are valid with respect to the ledger state after applying the incoming block, but will be _invalid_ when evaluated against the previous ledger state (since the transactions they depend on have not been applied in that state). This means that when we evaluate the mempool with respect to that prior ledger state, those dependent transactions from the mempool will be removed as invalid, and not be included in the block we produce.

This is /not/ addressed by the thread mentioned in the previous point: the transactions that are deleted from the mempool are not included in the incoming block, _nor_ in our block, and so we would not reintroduce them into the mempool simply if we monitor the chain.

From the perspective of another node, the situation is again slightly different. As above, if they don't end up adopting our block, what we decide here doesn't really matter. If they do, they simply wouldn't remove _either_ the transactions that had been included in the block produced by the other node, _nor_ the ones that we removed because they depended on them, and so they would be able to include all of them in the next block. This does however depend on other codes having the same transactions in their mempool.