v0.4.0+commit.18de11f

feat: multi-schema support when parsing/dumping (#20)

Customers may want to use pgmigrate's parsing/dumping logic with
migrations that interact with multiple different Postgres _schemas_
within the same database. Currently, the dumping logic doesn't support
this — the code assumes that you're interacting with a single schema,
which it assumes by default is named `public`. This PR changes that
assumption and makes it so that you can parse/dump multiple schemas
within the same database.

In order to make multiple-schemas work, I had to update the way the
internal schema-parsing code refers to objects — now objects must be
fully referenced including their schema, not just their name. This
prevents conflicts between objects with the same name in different
schemas, and in general opens the door to broader multi-schema support.

The code needs to make sure that schemas exist, which means quoting and
escaping their names correctly. Testing this led to minor
backwards-incompatible changes in the general quoting/escaping logic
used throughout the codebase. now, `hyphenated-object-names` will be
escaped as `"hyphenated-object-names"`; previously, they would not have
been escaped. I don't think this ever would have worked before, but it's
fixed now.

The `pgmigrate dump` configuration and its documentation needed updating
to make it clear that objects must be written as fully qualified
`schema.name` instead of `name`. The `schema: public` key was updated to
be a list of strings. These are backwards-incompatible changes.

Finally, I added the ability to add header and footer lines to the
dumped SQL schema when running `pgmigrate dump`, motivated by support
for functions that make queries against tables. pgmigrate always dumps
function definitions in the same order at the top of the file. While we
could make it possible for functions to depend on tables, this leads to
very complicated manually-specified dependency trees. It's simpler to
just use the new header options to set a transaction-local
[check_function_bodies](https://postgresqlco.nf/doc/en/param/check_function_bodies/)
parameter to let you create functions without validating their
definitions.

## Testing
- [x] lots of automated tests

## Breaking Changes
- `.pgmigrate.yaml` config format
- quoting/escaping logic now escapes `hyphenated-object-names`,
previously didn't.

## Followups
I'll have to tag versions `v0.4.0` and `cmd/pgmigrate/v0.4.0` manually
after this is merged. That should fix all the build stuff.