Containerize db migrations

[humphd]

In #3418, @DukeManh is adding automated database migrations via Prisma Migrate. It will allow us to detect when the database schema is out of sync with master, and generate a migration to be applied.

Running this requires network access to the Postgres database, which we have in local development, but not in production (i.e., we don't expose it at all).

Accessing the postgres database requires running our code within the Docker network. This means running the code via a container that runs inside our network. @JerryHue is doing something very similar with postgres backups in #3405.

Unlike the work that @JerryHue is doing, where we can run this automatically and all the time (i.e., we run backups as a cron job), migrations are a one-off action. We won't need them very often. I'd like to be able to run them via Portainer. The process would look like this:

1. We create a container in src/db that contains all the prisma migrations and code necessary to run them
2. In CI for staging and production, we build and push images to our registry; however, we don't ever use these images in our docker-compose
3. When we need to run a migration (e.g., on staging), we ask Portainer to create a new container based on docker.cdot.systems/migrations:staging (or whatever we name it). The same would happen for production (e.g., using:production).

This should mean that the migrations are always in sync with what's needed on the particular environment where we need to run them, since they are built from git on each push/tag.

Our first migrations are needed before 3.0 (see #3433), so we should be able to test this process, document it, and fix any bugs.