Update `miners` StackerDB to handle multiple bad sortitions

We have multiple workstreams (mainly #5452) presently where a TenureExtend is created, even if a new BTC block has a winning miner. As part of testing for this feature, we've learned that there is an edge case where, if there are two bad sortition winners in a row, the "good" miner cannot TenureExtend a second time, because they can't write to the miners StackerDB contract. This is because the miners StackerDB only allows writes from the current and previous sortition winner.

I think there are a few potential paths forward for this:

• Modify make_miners_stackerdb_config to allow either the sortition winner OR the miner who was able to successfully TenureExtend the previous block to write to this slot.
• Make a new StackerDB, like miners-v2, which allows N previous sortition winners to write to it. This technically can run into the same issue as described here, even if N was something high like ~10.