Make migrations work for real and in test

DEFRA/water-abstraction-team#106

This project is already using the migration engine we want to use ([Knex migrations](https://knexjs.org/guide/migrations.html)). But we are working in a 'weird-world' where the migrations we've written are focused on creating tables that already exist. This is because we are dealing with a legacy service with an existing DB.

Because of this, we can only run these migrations against a test DB. We are now working on a feature where for the first time we need to create 'real' tables. We'd _love_ to do this in **water-abstraction-system** but because of how we've set things up have we've managed to lock ourselves out of doing this. We can't just add our new 'proper' migrations amongst the ones we've created to support unit tests.

This change is about sorting that problem. Now when we run migrations in a non-test environment only those found in `db/migrations/public` will be run. However, in our CI and when running unit tests locally we can run the existing create legacy table migrations followed by the 'real' migrations.

To confirm this we add 'real' migrations to create 3 new views. Going forward when we need to reference a legacy table we intend to do so through a view. Doing so means we can

- rename the 'table' to reflect what is actually in it!
- rename fields that annoy us, for example, `foo_bar_wiggle_thompson_id` just becomes `id` 😁
- rename fields to be standard, for example, `date_created` becomes `created_at`
- ignore fields that don't seem to be populated, or that don't vary

We also tidy up the commands we use in `package.json` as we need to make changes to support this.