vitess: add vschemas with vindexes

[jsha]

In order to exercise sharding logic in Vitess, we need our integration test environment to use sharded keyspaces, which means we need to use vindexes. This PR enables vindexes and changes DB initialization in support. It does not yet shard the keyspaces since doing so causes some consistency issues I still need to debug.

DB initialization: stop using sql-migrate inside the boulder container. Make the bmariadb and bvitess containers responsible for applying schemas when they start up. Use different database / keyspace names for different test environments: boulder_sa / boulder_sa_next. This allows the two to coexist, which means we don't need to down --volumes the bmariadb container when running locally and switching from ./tn.sh to ./t.sh. The bmariadb image has support for applying SQL schemas from a directory. The vttestserver has support for applying SQL schemas and vschemas from a directory.

Note: for the sake of getting things working, I made a separate copy of the SQL schema for each of (mariadb, vitess) x (boulder_sa, boulder_sa_next). This is definitely not good enough since they will drift out of date. Looking for feedback on the cleanest way to use a single source of truth. One obstacle: the SQL files used for bmariadb must have a USE statement at the top. The SQL files use for bvitess must not have a USE statement at the top (the keyspace name comes from the directory structure).

Foreign keys: we had one foreign key constraint (serials.registrationID -> registrations), but we probably don't actually want this in the Vitess world. It makes things more complicated with no benefit. I removed it from the SQL schemas.

test/db.go: In vttestserver we can't delete more than 10k rows, so I changed deleteEverythingInAllTables to delete in a loop. Incidentally I cleaned up some stuff about foreign keys and 1 = 1 that is no longer needed. Also, I changed deletion calls in sa_test.go to use the shared deletion functions.

test/vars/vars.go: calculate DSNs based on the BOULDER_CONFIG_DIR variables, to select between boulder_sa and boulder_sa_next (etc.).