Fix database cleaning breaking migrations

Recently the team have found they repeatedly have to wipe the schemas, tables and views from their local `water_system_test` DB.

We initially put it down to us changing migrations that might have already been run.

> As a team we are happy for migrations that have yet to be run in production to be edited. Typically a migration is one of the first things created when working on a new feature but you don't know what you actually need until the feature is complete.

But we now know it was when we started [Persisting the results data from the two-part tariff match and allocate service](#616). We added `public` to the list of schemas the database helper should clean but overlooked that is also where our migrations tables sit.

So, we'd become locked in a cycle.

- Attempt to run migrations and they fail (because they are trying to create things that already exist)
- Delete schemas, and tables and views in `public` manually
- Re-run migrations and all is well
- Run unit tests which inadvertently delete migration records
- All is well for awhile
- Someone adds a new migration
- Go back to step one

This change fixes the issue by ensuring the Knex migration tables are ignored by the database helper when cleaning.

test/support/helpers/database.helper.js

@@ -8,7 +8,7 @@
  * @module DatabaseHelper
  */
 
-const { db } = require('../../../db/db.js')
+const { db, dbConfig } = require('../../../db/db.js')
 
 /**
  * Call to clean the database of all data
@@ -27,10 +27,15 @@ async function clean () {
   }
 }
 
+function _migrationTables () {
+  return [dbConfig.migrations.tableName, `${dbConfig.migrations.tableName}_lock`]
+}
+
 async function _tableNames (schema) {
   const result = await db('pg_tables')
     .select('tablename')
     .where('schemaname', schema)
+    .whereNotIn('tablename', _migrationTables())
 
   return result.map((table) => {
     return `"${schema}".${table.tablename}`