They don't seem to be used. Also improve the comments on the wrapper
types.

…types

Redistribute how PostgreSQL types are handled. Creating a PostgreSQL
type from an OID and typmod is now handled entirely by `pgrepr::Type`.
The `postgres_util::PgColumn` struct now stores a `pgrepr::Type`
directly, rather than a separate `PgScalarType` enum that was relatively
duplicative with `pgrepr::Type`.

The `sql` crate now generates views for a PostgreSQL source by
converting a `pgrepr::Type` to an `UnresolvedDataType` by way of a new
`fmt::Display` implementation on `pgrepr::Type`.

For safety, the modifiers on `ScalarType::{Numeric,VarChar,Char}` now
have newtype wrappers that enforce the bounds at construction. For
clarity, the `scale` parameter of `ScalarType::Numeric` has been renamed
`max_scale` and the `length` parameter of `ScalarType::VarChar` has been
renamed `max_length`, to better reflect that they are maximums, not hard
requirements. This is in contrast to `ScalarType::Char`, where the
length is in fact a hard requirement, not a maximum.

Store types in the catalog via a new CatalogType enum. This enum is
nearly one-to-one with ScalarType, except that modifier fields are
removed and embedded types are replaced with GlobalId references.

This type is used throughout the SQL planner, in the plans returned by
`CREATE TYPE` and in the type name resolution code.

The motivation for this refactor is the removal of the "lossy"
conversions from `pgrepr::Type` to `ScalarType`. Now, all conversions
are either full fidelity or report an error if they would discard data.