feat: use golang migrate

[kian99]

Description

This PR removes our home-grown migration code in favour of golang-migrate.

Some reservations I had with Golang-migrate over Goose and why I'm okay with it now:

• Migrations, by default, are not run in a transaction.
  • Thanks to Postgres and multi-statements, each migration file is run in a transaction. If we want to move to a different SQL DB or be more explicit we can add BEGIN/COMMIT statements to our transactions.
• Large set of dependencies in the golang-migrate library.
  • After importing the library and the Postgres driver, we only have 4 new indirect dependencies so it doesn't seem too bad.
• When a migration fails, the DB is marked as "dirty" and requires manual intervention.
  • Thanks to Postgres/transactions, we don't end up in an inconsistent state and when we detect this we can handle it in code. I've also added a test for this.

I recommend reviewing this PR commit-by-commit to more easily see the changes.

The benefits this gives us aren't huge. One benefit is that we don't need to modify the versions.go file when we add a new migration file, it will just automatically be applied, leaving less room for error.

Fixes JUJU-7047

Engineering checklist

• Documentation updated
• Covered by unit tests
• Covered by integration tests

Test instructions

To test the new migrations on a fresh DB, just docker compose --profile dev up.

To test migrations on a DB that was using the old-style migrations. Switch to the v3 branch then ``docker compose --profile dev up` then switch to this branch and observe the jimm logs.

[SimoneDutto]

nice work, left some comments

[SimoneDutto]

why don't we also check this flag at the start of the Migrate method?

[kian99]

We could, but we didn't before so I haven't changed that logic.

[SimoneDutto]

i guess it's uncommon we call the Migrate twice in our tests, because we usually create a new db for each test.

[SimoneDutto]

lgtm