Some comments that are meant to separate blocks of code in a file show up
on http://api.rubyonrails.org as though they were part of the documentation.

This commit hides those comments from the documentation.

Stems from the discussion with @zzak at https://github.com/voloko/sdoc/issues/79#issuecomment-64158738

[ci skip]

  - remove unused method `supports_add_column?`
  - change additional restriction method to `valid_alter_table_type?`
  - fix code style

The `select` method has the same definition in almost all database
adapters, so it can be moved from the database-specific adapters
(PostgreSQl, MySQL, SQLite) to the abstract `database_statement`:

```ruby
def select(sql, name = nil, binds = [])
  exec_query(sql, name, binds)
end
```

---

More details about this commit: the only two DB-specific adapters
that have a different definition of `select` are MySQLAdapter and
MySQL2Adapter.

In MySQLAdapter, `select` invokes `exec_query(sql, name, binds)`, so
calling `super` achieves the same goal with less repetition.

In MySQL2Adapter, `select` invokes `exec_query(sql, name)`, that is,
it does not pass the `binds` parameter like other methods do. However,
[MySQL2Adapter's `exec_query`](https://github.com/rails/rails/blob/74a527cc63ef56f3d0a42cf638299958dc7cb08c/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb#L228L231)
works exactly the same whether this parameters is passed or not, so the output
does not change:

```ruby
def exec_query(sql, name = 'SQL', binds = [])
  result = execute(sql, name)
  ActiveRecord::Result.new(result.fields, result.to_a)
end
```

`AbstractAdapter#supports_views?` defaults to `false` so we have to turn it on
in adapter subclasses. Currently the flag only controls test execution.

/cc @yahonda

As of https://github.com/rails/rails/commit/e781aa31fc52a7c696115302ef4d4e02bfd1533b SQLite3Column has been dropped.

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.