Remove cluster hooks in favour of pg_dumpall -g

[JAForbes]

We've got an always hook that runs always, but after the transaction. But maybe we should rename it to post and have a pre hook. Both hooks would always run and could be used to create roles using a declarative util.

I want to remove the cluster hooks concept (see #46). Hostname isn't a good property to rely on to detect change.

We also tend to configure our local env so the production db url is the same as the local db url within a docker container. So relying on the hostname in the db url isn't great either.

I also considered having a top level export for roles, but we would need to diff them to see if properties change and that mixes metaphors because pgmg is declarative, so having a single declarative hook feels like it could cause confusion and lead to surprise if it does or doesn't respond to change.

[JAForbes]

I've been playing with a new revision that has pre/post and no cluster hooks, but I think the use case is a little flaky. Yeah you could create roles (with the new util) in pre and do grants in post, then you won't need do use pg_dumpall -g to seed roles.

But it requires too much knowledge of the execution of pgmg and its awkward to define grants / roles in these separate hooks that always run.

I think restoring a local prod snapshot is something pgmg shouldn't do because I've found from project to project we tweak the config of how local prod works. If pgmg has opinions about restoring local backups then it becomes inflexible for end users.

But the primary reason pgmg exists is for Harth to have a simple migration process across projects, so if we bake in a restore command then it will be beneficial to us and we can remove the reliance on pre/post for every single migration script. If we can assume roles/grants are managed by restore then everything becomes simpler for a local dev workflow.

So now I think we still do drop cluster hooks / hostname diffing. But we assume roles/grants are already present. In a later release we can add a restore command but for now we just document the assumptions about the end users restore process.

I think we still keep pre/post but we do not rely on them for normal migrations, they are there for special edge cases for the users benefit.