Improve failure-case property test coverage for the `LargeSmtForest`

### What should be done?

In general, we state a number of hard-to-test guarantees about the state of the forest being left in a valid state after certain kinds of errors occur, and it would be good to expand coverage of such cases.

### How should it be done?

We currently have the `FallibleEntriesBackend`, used to test failure cases in the entries iterator. We can expand this to our own "chaos monkey" that creates specified failures in all backend calls. I would like to see:

- The `FallibleEntriesBackend` become the `FallibleBackend`.
- It to take a `Config` on construction which specifies _how_ and _when_ it will fail (in predictable ways). For example, we want to be able to construct an instance where `entries` fails after yielding three items (the current behaviour), or a separate instance where `add_lineage` fails in the _backend_.

With this done, we can then add a parallel set of property-based tests that check that the full forest does the correct thing in the presence of a variety of failures. I'm particularly interested in the replication of failure scenarios we would see in the _persistent_ backend (e.g. disk access failures), even though it should continue to delegate to the `InMemoryBackend` for successful paths.

### When is this task done?

When the above changes, or semantically-equivalent ones, have been made, and are exercised properly in fully-passing tests.

### Additional context

Created in light of my comment [here](https://github.com/0xMiden/crypto/pull/886#pullrequestreview-3992525500).