adapter, fixed from #16057 [ci skip]

Note: I'm not sure we actually need to be logging when this happens.
This code would be a fair bit cleaner if we didn't need to log it.

- 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.

All subclasses of column were now delegating `type_cast` to their
injected type object. We can remove the overriding methods, and
generalize it on the `Column` class itself. This also enabled us to
remove several column classes completely, as they no longer had any
meaningful behavior of their own.

The `:timestamp` type for columns is unused. All database adapters treat
them as the same database type. All code in `ActiveRecord` which changes
its behavior based on the column's type acts the same in both cases.
However, when the type is passed to code that checks for the `:datetime`
type, but not `:timestamp` (such as XML serialization), the result is
unexpected behavior.

Existing schema definitions will continue to work, and the `timestamp`
type is transparently aliased to `datetime`.

Part of #15134. In order to perform typecasting polymorphically, we need
to add another argument to the constructor. The order was chosen to
match the `oid_type` on `PostgreSQLColumn`.

There is no reason for the PG adapter to have a default limit of 255 on :string
columns. See this snippet from the PG docs:

    Tip: There is no performance difference among these three types, apart
    from increased storage space when using the blank-padded type, and a
    few extra CPU cycles to check the length when storing into a
    length-constrained column. While character(n) has performance
    advantages in some other database systems, there is no such advantage
    in PostgreSQL; in fact character(n) is usually the slowest of the
    three because of its additional storage costs. In most situations text
    or character varying should be used instead.

* Clarify what the situation is and what to do.
* Advise loading schema using `rake db:setup` instead of migrating.
* Use a rescue in the initializer rather than extending the error
  message in-place.
* Preserve the original backtrace of other errors by using `raise`
  rather than raising again with `raise error`.

References 0ec45cd1

This was a common pattern:
```
query = author.posts.select(:title)
connection.select_one(query)
```

However `.select` returns a ActiveRecord::AssociationRelation, which has
the bind information, so we can use that to get the right sql query.

Also fix select_rows on postgress and sqlite3 that were not using the binds

[fixes #7538]
[fixes #12017]
[related #13731]
[related #12056]

SQLite3 adapter must make sure to close statements after queries.

Fixes: #13631

Building on the work of #13427 this PR adds a helpful error message to the adapters: mysql, mysql2, and sqlite3

    
This has returned true since 3cc9b5f1, and is not used internally.

Drop some comments that document the implementation rather than the interface.

The log output used to be confusing in situation where type casting has
"unexpected" effects. For example when finding records with a `String`.

BEFORE:

irb(main):002:0> Event.find("im-no-integer")
D, [2013-11-09T11:10:28.998857 #1706] DEBUG -- :   Event Load (4.5ms)  SELECT "events".* FROM "events" WHERE "events"."id" = $1 LIMIT 1  [["id", "im-no-integer"]]

AFTER:

irb(main):002:0> Event.find("im-no-integer")
D, [2013-11-09T11:10:28.998857 #1706] DEBUG -- :   Event Load (4.5ms)  SELECT "events".* FROM "events" WHERE "events"."id" = $1 LIMIT 1  [["id", 0]]

Remove `default_primary_key_type`  and extract contains of `native_database_types` to a constant since they aren't conditional now in SQLite3Adapter. Makes it more like other adapters.

When the adapter is with prepared statement disabled and the binds array
is not empty the connection adapter will try to set the binds values and
will fail. Now we are checking if the adapter has the prepared statement
disabled.

Fixes #12023

This change was breaking the Railties tests. See
https://travis-ci.org/rails/rails/jobs/9865969

If the `db/` directory is not present on a remote machine it will blow up in unexpected ways with error messages that do not indicate there is a missing directory:

```
SQLite3::CantOpenException: unable to open database file
```

This PR checks to see if a directory exists for the sqlite3 file and if not creates it for you.

This PR is an alternative to #11692 as suggested by @josevalim

added comments to test_invalid_type in sqlite3 adapter test and added valid_type? method to abstract_adapter.rb and removed unnecessary method from sqlite3 adapter

Created a layer of abstraction for the valid type checking in schema dumper. Now, connection handles the check for valid types so that each database can handle the changes individually.