Propagate the additional-handle-for-testing idiom

The origin of this idea was PR https://github.com/IntersectMBO/ouroboros-consensus/pull/1831 --- I added a method to the `Mempool` handle record type that's "only for testing". There were a few there already.

In retrospect, I'm wondering if I should have instead done a refactoring to match the `ChainDB` API, where the official `open` function is nothing more than a wrapper around `openInternal`, which yields the proper `ChainDB` handle but also an `Internal` handle, which exposes stuff that we'd only ever use for testing, eg.

I think the separation in the `ChainDB` API is better, and this Issue would be to propagate it to our other major components (TODO list).

It might even be worthwhile for components that currently don't have any testing-specific methods, so that there's less disruption when a new testing thing is added. YAGNI on one hand, but on the other hand consistent APIs has benefits.

One last _possible_ extreme to mention: we could choose to ignore changes to the `Internal` handle when deciding version bumps, since our test suites are not stably versions and these `Internal` handles should absolutely not be used by anything other than our tests---or at least if someone does choose to use them then they should not expect to benefit from our careful versioning of our _stable_ APIs.

Start by reading PR 1831 and the existing ChainDB API, especially the relationship between open and openInternal. Compare that pattern with the Mempool handle and identify the other major components in the TODO list that need the same separation. Done means the chosen components expose consistent testing-only Internal handles without changing the stable APIs.

Written by the indexing model from the issue text.