Facilitate stub data spinup for non production environments

[bytesandwich]

Whenever we manage schema migrations for non production environments, we invariably need to follow up with stub data inserts. Integrating stub data with our schema tool makes sense for two reasons:

1. In order to insert stub data, we need to know that the schema updates have finished and the necessary tables exist. The schema tool is the easiest place to resolve the temporal dependency between schema migrations and stub data. Otherwise, what do we wait for?
2. If we track schema changes with stub data changes, we can test in ci that a change to one doesn't break the other, so both are always in a useful state.

I propose that we track stub data in a separate directory of our schema repos, and add a new command analogous to running up and then also applying stub data sql files from some conventional project directory.

It may seem desirable to also add commands to add/remove only stub data, without affecting table definitions, but I argue that dev/test environments should be essentially immutable and defined at the granularity of create/destroy. We don't need to track a stub data alter chain. The more we fiddle with stub data, the harder it is to reproduce our dev/test environment. I think the proposed command with rebuild -f should be adequate.