postgresql: Add foreign key constraints the first time when migrating

[hdgarrood]

I'm pretty sure there isn't an issue for this already, which is a bit surprising! But in postgresql, when you add a foreign key column to an existing table, you need to generate migrations twice to get it fully set up: the first run only creates the column, and the second creates the FK constraint.

This PR adds a test demonstrating the issue as well as removing a guard which I'm reasonably confident isn't necessary (see #1169 (comment)). The commit titled "refactor: don't match on all of the Column fields" also does a refactor to avoid matching on each of the fields of the Column values, so that it's obvious which values come from the old vs new column, since I found it quite hard to get my head around what this function was doing to start with, but I'm happy to revert that one if you don't think it's an improvement. I recommend reviewing that commit separately from the others.

After submitting your PR:

• Update the Changelog.md file with a link to your PR
• Bumped the version number if there isn't an (unreleased) on the Changelog
• Check that CI passes (or if it fails, for reasons unrelated to your change, like CI timeouts)

[hdgarrood]

This needs a bit more work to work around #1615

[hdgarrood]

Ok - confirmed that the tests fail on the new ExplicitPrimaryKey entity if I get rid of this line:

    refAdd _ | fmap fieldDB (getEntityIdField edef) == Just (cName newCol) = []

and pass with it.

[parsonsmatt]

hell yeah

[hdgarrood]

This guard is basically the same as it was before - before, we were checking against the old column's name, and now we're checking against the new column's name, because there won't always be an old column name to check against (eg in the event that the column doesn't yet exist). There's no meaningful difference - previously, we would only ever run this check after verifying that the old column name matched the new column name.