The name field is no longer supported as of #852.

Follow up to #852.

#852 removed support for specifying a migration name via the `name`
field in a migration file. While having an unambiguous source of truth
for the migration name (the filename) is good, it is still often
desirable to decouple the filename from the name of the version schema
that the migration will create when applied because filenames:

* can be longer than the limit Postgres imposes on schema names
* can contain characters that are not legal in Postgres schema names
* must be named so that migration files are ordered lexicographically on
disk

This PR adds support for a new `version_schema` field in migration files
that allows the migration author to specify the name of the version
schema that the migration will create.

## Example

```yaml
# migration files can now specify the version schema 
# name to be created by the migration
version_schema: my_version_schema
operations:
  - create_table:
      name: items
      columns:
        - name: id
          type: serial
          pk: true
        - name: name
          type: varchar(255)
```

Running this migration:

```
$ pgroll start migrations/01_create_table.yaml --complete
```

Creates this version schema:

```
+-----------------------+-------------------+
| Name                  | Owner             |
|-----------------------+-------------------|
...
| public_my_version_schema | postgres       |
+-----------------------+-------------------+
```

Had the `version_schema` field not been specified in the migration file
the version schema would have been:

```
+-----------------------+-------------------+
| Name                  | Owner             |
|-----------------------+-------------------|
...
| public_01_create_table | postgres         |
+-----------------------+-------------------+
```

---

This PR is part of a stack:
* #884 (this PR)
* #886
* #887

Part of #882