When table has a composite primary key, the `primary_key` method for
sqlite3 and postgresql was only returning the first field of the key.

Ensures that it will return nil instead, as AR dont support composite pks.

This allows us so abstract the migration from the type that is actually
used by Rails.  For example, ":string" may be a varchar or something,
but the framework does that translation, and the app shouldn't need to
know.

Also checked to make sure this does not affect foreign key constraints.
(It doesn't).

Fixes #12856
Closes #14088

Skip setting sequence on a table create if the value is 0 since it will start the first value at 1 anyway.
This fixes the PG error 'setval: value 0 is out of bounds for sequence vms_id_seq...' encountered when migrating a new DB.

BugzID: 15452,9772,13475,16850

While investigating #16951 I found that another library's monkey-patching of
`Enumerable` was causing the test migrations helper to break when trying to
build the `CREATE DATABASE` statement. The prior approach used `#sum` to build
the string from the options hash.

As the code that combines the options to build the database statement is not
user-facing, using `#inject` here instead will remove the only place where the
database creation/migration code is dependent on ActiveSupport's monkey-patching
of `Enumerable`.

Closes #16907.

[Matthew Draper & Yves Senn]

This is a reacon to https://github.com/rails/rails/commit/d6c1205584b1ba597db4071b168681678b1e9875#commitcomment-7502487
This backwards incompatibility was introduced with d6c12055 to fix #7516.
However both `connection.default_sequence_name` and `model.sequence_name` are public API.
The PostgreSQL adapter should honor the interface and return strings.

/cc @matthewd @chancancode

* Require either FIRST or LAST qualifier for "NULLS ..."
* Require whitespace before "NULLS ..."

Fixes #16623 introduced by https://github.com/rails/rails/commit/3d5a2019bcccc6fb01bee4811ca669f4383edb51

Closes #16261.

[Matthew Draper, Yves Senn]

Using `DEFAULT NULL` results in the same behavior as `DROP DEFAULT`.
However, PostgreSQL will cast the default to the columns type,
which leaves us with a default like "default NULL::character varying".

/cc @matthewd

The only case where we got a column that was not `nil`, but did not
respond to `cast_type` was when type casting the default value during
schema creation. We can look up the cast type, and add that object to
the column definition. Will allow us to consistently rely on the type
objects for type casting in all directions.

This is an intermediate solution. It is related to the refactoring @sgrif
is making and will change in the future.

- Create a consistent API across adapters for building new columns
- Use it for custom properties so we don't get `UndefinedMethodError`s
  in stuff I'm implementing elsewhere.

Determining things like precision and scale in postgresql will require
the given blocks to take additional arguments besides the OID.

- Adds the ability to handle additional arguments to `TypeMap`
- Passes the column type to blocks when looking up PG types

Partial revert of c0bfc3f4