me: fix regression w/ mapped enum names on postgres

[tomhoule]

When calculating a SQL schema from a Prisma schema, the Postgres
connector of the migration engine would use the name of the enum instead
of its database name (see parser-database docs for the reference on what
these mean). To picture this with an example, the following schema.

enum PersonType {
  Dog
  Cat
  @@Map("pet_preference")
}

would correspond, before the regression, and after this commit, to:

CREATE TYPE "pet_preference" AS ENUM ('Dog', 'Cat');

but the regression caused it to correspond to:

CREATE TYPE "PersonType" AS ENUM ('Dog', 'Cat');

This does not only affect newly created enums: we diff the wrong enums,
causing bad migrations for existing users of Migrate that have the enums
with the correct (mapped) names in their database.

Users reported the regression in prisma/prisma#16180
This commit should completely fix the problem.

The regression was introduced in an unrelated refactoring in
b6400f1. Enum names in column types
were replace with enum ids — a win for correctness. As part of this
refactoring, the sql_schema_describer::Enum type was made private, and
adding enums to a schema became possible only through
SqlSchema::push_enum. In the SQL migration connector

What could have caught this:

• Testing that the name of the database enum in the migration is the
  mapped name. We can test this:
  • Through .assert_schema(), which has existed for a long time.
    It is a gap in our test coverage that we weren't testing this.
  • The new single migration tests, like the test in this commit.
    They are new, and they are less work than the previous option.
• migrations-ci could have caught this, but it is currently neglected.

[tomhoule]

Looking into the vitess test failures.

edit: they're almost certainly unrelated, see the PR in my next comment.

[tomhoule]

#3369