Evaluate ROI of maintaining `RegressionProviderFactory`

### Problem

The `RegressionProviderFactory` infrastructure lets us create tests that submit random mixtures of HAPI operations with different probabilities of each operation being chosen.

The idea is to randomly push the target network into parts of its "state space" that are hard to systematically label and test by hand.

This has occasionally surfaced issues that normal testing did not. But the `RegressionProviderFactory` is undocumented and keeps a lot of fairly intricate code in the repository with unclear benefits.

### Solution

Evaluate whether `RegressionProviderFactory` can be effectively documented and kept up-to-date with new HAPI operations as we implement further HIPs.

If not, clearly document it is as just providing coverage of pre-existing functionality and consider a better way to accomplish the same kind of testing goal.

### Alternatives

_No response_

Start by locating the RegressionProviderFactory infrastructure and the tests that use it, then review how it generates random mixtures of HAPI operations. Evaluate its benefits against the maintenance needed for new HIPs. Done means documenting whether it should be maintained, documenting its coverage limits if retained, or proposing a better testing approach.

Written by the indexing model from the issue text.