db-migrations: use pg for new migrations

[alxndrsn]

• implement replacement for existing knex migrator

Blocked by

• blobs: prevent NULL contentType in db #1355

TODO

• resolve inline TODOs, FIXMEs etc
• rewrite unreleased existing migrations with the new approach (one migration should be introduced by blobs: prevent NULL contentType in db #1355)
• separate PR for connectionObject rename (knex: rename connection object #1364)
• separate PR for connect rename (db-migrate: rename knex-specific functions #1372)
• add eslint warnings for app-level imports into migrations files (db-migrations: prevent new uses of application code #1371)
• fix db migration tests

Follow-up

• rename knex-migrator
• move existing migrations to lib/model/migrations/legacy to dissuade creating new knex-based migrations

What has been done to verify that this works as intended?

CI

Why is this the best possible solution? Were any other approaches considered?

Could use slonik instead, but seems better to tie implementation to a lower-level library, especially given concerns about upgrading to a more recent slonik (there are large API changes) and/or possibility of moving to an alternative to slonik.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Intended effects: none
Possible effects: break production databases

Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.

Shouldn't require docs changes.

Before submitting this PR, please make sure you have:

• run make test and confirmed all checks still pass OR confirm CircleCI build passes
• verified that any code from external sources are properly credited in comments or that everything is internally sourced

[alxndrsn]

Renamed in #1384