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

In #10410 it was noted that you can no longer create PK's with the
type of bigserial in PostgreSQL in 4.0.0.rc1. This is mostly
because the newer adapter is checking for column type with the
id column instead of just letting it pass through like it did
before.

Side effects:
You may just create a PK column of a type that you really don't
want to be your PK. As far as I can tell this was allowed in 3.2.X
and perhaps an exception should be raised if you try and do
something extremely dumb.

Changed change_column in PG schema_statements.rb to make sure that the uuid_generate function was not being quoted.

[Yves Senn & Matthew Draper]

Expand the query used in #table_exists? to include materialized views in the
kinds of relations it searches.

The pk_an_sequence_for query previously joined against pg_class's oid
for rows in pg_depend, but pg_depend's objid may point to other system
tables, such as pg_attrdef.  If a row in one of those other tables
coincidentally has the same oid as an (unrelated) sequence, that
sequence name may be returned instead of the real one.

This ensures that only the pg_depend entries pointing to pg_class are
considered.

Reject blank order_values within #columns_for_distinct, as the orders aren't used at all on non-postgres adapters.

The combination of a :uniq => true association and the #distinct call
in #construct_limited_ids_condition combine to create invalid SQL, because
we're explicitly selecting DISTINCT, and also sending #distinct on to AREL,
via the relation#distinct_value.

Rather than build a select distinct clause in #construct_limited_ids_condition,
I set #distinct! and pass just the columns into the select statement.
This requires introducing a #columns_for_distinct method to return the
select columns but not the statement itself.

When building the indexes list in PostgreSQL, IndexDefinition objects
are only created if the query for the related attributes really returns
something matching the attributes.

In case it does not, the variables for building the definition objects were
being created but not used.

Adds support for algorithm option in MySQL indexes
Moves USING and algorithm options upstream

The syntax is still specific to the Adapter, so the actual executed string happens
in the corresponding adapter