Support programmatic generation of all StreamFields (just GuidePage for now)

In the process of https://github.com/cityofaustin/techstack/issues/3630 , we learned that generating test data for StreamFields is a bit more involved and nested StreamFields (which we use a lot )not supported out of the gate with wagtail_factories.

I got in contact with NHSUK, which had forked off their own version of wagtail_factories to add additional support. We're going to work together to make that a PR back to the original project.

However, the enhancements they have made so far don't benefit us immediately, mostly because of differences in how our StreamFields are structured. It's not clear how easily factory_boy or wagtail_factories supports generating nested data in particular. Though I got my hands on the source code for NHS stuff, so I can see some examples of ways they have worked around it, it's going to take some more effort to get what we want.

## So what do we want?
(some examples)
For a GuidePage:
* A Guide page has sections, which is a StructBlock
* each section has a heading, which we want to generate placeholder text for
* it then has a list of PageChooserBlocks
* We want to generate a random but reasonable number of related PageChooserBlocks
* For each PageChooserBlock, we want to randomly pick a info page or service page

For a ServicePage:
* A Service Page has steps
* A step can be one of 3 types (currently)
* We want to generate a random number of steps, with a random selection of which type of step, and test
data for all the content of that step

## Why is this good?

It gives us a very good approximation of 'real world' test data, so load and performance testing and refactoring along those goals has the highest chance of actually making things better.

It's also good because it means we're doing more robust testing, and there is less likely to be bugs that slip by because of gaps in test data (which happens often at the moment).

It also means that the test data can be generated as the test is run, skipping the time-intensive part of dumping and/or loading data for the purpose of testing.

## Why not use fixtures or load in some pre-created data for sections?

This could give us false positives or negatives for performance or load testing.

For example, if the number and relation of related pages is consistent and predictable, there are types of indexing that would seem to be natural choices for optimizing performance, and tests might even show improvement, but those improvements would fail to materialize in production if the real-world data is not as predictable (which it won't be).