Table constraints are now keyed according to what they constrain instead
of all of their attributes, including names.

No "type of all constraints, one at a time".  separate types for PRIMARY
KEY, UNIQUE, and FOREIGN KEY constraints; all split into the "match" and
"extra" parts.  All such constraints are now collected into a record of
maps, with the key being the match part of that constraint type and all
other data in the value of the map.

In most places for constraint/sequence, the name is wrapped in a Maybe,
to instruct beam-automigrate to allow postgres to choose the name, or
use the name from the db for existing, matching entity.

Sequences are now (optionally) owned by "SERIAL" columns using the built
in "OWNED BY" syntax in postgres.  A serial column can have an optional
name; beam-migrate will learn the name chosen by postgres at startup
when it already exists.

string parsing of DEFAULT constraints are now handled with a self
contained attoparsec based parser in `D.B.A.Parser`.  It's only parsing
the fragment of sql that beam-automigrate needs to understand to do it's
job; but is a good start for gradually improving its precision as the
need arises (future check-constraint support, as an example)

More liberal use of `"lens"` library to make some code a little easier
to understand.

Fixes dodgy catalog sql query for retrieving foreign key constraints.
how did this ever work?

… as soon as it was added

Before ("NULLDEFAULT"):
        CREATE TABLE cities (capital BOOL NOT NULLDEFAULT
        'false'::boolean, city VARCHAR NOT NULL, location VARCHAR NOT
        NULL);

After:
        CREATE TABLE cities (capital BOOL NOT NULL DEFAULT
        'false'::boolean, city VARCHAR NOT NULL , location VARCHAR NOT
        NULL );

Previous commits introduce a bug where no migration is assumed if both
versions of a table have a primary key at all,  This commit fixes the
case when both versions have a PK but with different columns.

This also exposed a related bug that primary key migrations must be
handled differently to unique key migrations.  a table can have only one
PK, which has further affects on when foreign key constraints must be
added or removed.

Otherwise, SequenceSetOwner will be executed on the new name before it has been renamed

…de the same transaction

Namely runMigrationWithEditUpdateAndHooksDryRun and tryRunMigrationsWithEditUpdateAndHooksDryRun

…ctions

As the function name implies, the functions that start with "tryRunMigrationsWithEditUpdate" should take an "editUpdate" argument -- just like their "runMigrationWithEditUpdate"-counterparts.

…unctions

…utomigrate into cg/pre-post-hooks