Optimize select_value, select_values, select_rows and dry up checking whether to exec with cache for Postgresql adapter

Reduces creating unused objects, with the most dramatic reduction in select_values which used to map(&:first) an array of single element arrays.

[Yves Senn & Matthew Draper]

[Yves Senn & Matthew Draper]

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.

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

* 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 is a follow-up fix to f7a6b115 and
06082f66

This patch registers custom domains in our OID-type_map.
They will behave exactly as the type specified by `pg_type.typbasetype`.

/cc @matthewd

We have `connection_adapters/column.rb` so it's easier to remember
that the column in in a separate file.

.. not a general timeout.

Now, if a thread checks out a connection then dies, we can immediately
recover that connection and re-use it.

This should alleviate the pool exhaustion discussed in #12867. More
importantly, it entirely avoids the potential issues of the reaper
attempting to check whether connections are still active: as long as the
owning thread is alive, the connection is its business alone.

As a no-op reap is now trivial (only entails checking a thread status
per connection), we can also perform one in-line any time we decide to
sleep for a connection.

It wasn't doing anything beyond clearing the statement cache.

citext makes it possible to use AR Hash finders for case-insensitive matching as sql UPPER/LOWER functions are not needed.

- unused variable in PG Adapter.
- Ambiguous argument warning from range_test for use - to + Infinity range without brackets.

This gets AR working with custom defined range types. It also
removes the need for subtype specific branches in `OID::Range`.

This expands the interface of all `OID` types with the `infinity` method.
It's responsible to provide a value for positive and negative infinity.

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]

  - Earlier, change_table was creating database-agnostic object.
  - After this change, it will create correct object based on current
    database adapter.
  - This will ensure that create_table and change_table will get same objects.
  - This makes update_table_definition method public and nodoc.
  - Fixes #13577 and #13503

The code uses these checks in several places to know what to do with a
particular column, for instance AR attribute query methods has a branch
like this:

    if column.number?
      !value.zero?
    end

This should never be true for array columns, since it would be the same
as running [].zero?, which results in a NoMethodError exception.

Fixing this by ensuring that array columns in PostgreSQL never return
true for number?/text? checks.

Since most of the array support was based on the postgres_ext lib, it's
worth noting it does the same thing for numeric array columns too:

https://github.com/dockyard/postgres_ext/blob/v1.0.0/lib/postgres_ext/active_record/connection_adapters/postgres_adapter.rb#L72

This extended the same logic for text columns to ensure consistency.

Currently if you attempt to use a database that does not exist  you get an error:

```
PG::ConnectionBad FATAL:  database "db_error" does not exist
```

The solution is easy, create and migrate your database however new developers may not know these commands by memory. Instead of requiring the developer to search for a solution, tell them how to fix the problem in the error message:

```
ActiveRecord::NoDatabase: FATAL:  database "db_error" does not exist
Run `$ bin/rake db:create db:migrate` to create your database
```

Active Record should not know about `rake db:migrate` so this additional information needs to come from the railtie. Potential alternative implementation suggestions are welcome.

Previously, executing an insert SQL in PostgreSQL with a command like this:

    insert into articles(
      number)
    values(
      5152
    )

would not work because the adapter was unable to extract the correct articles table name.

also override drop_table in AbstractMySQLAdapter to properly drop
temporary tables without committing the transaction

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

This is necessary because as of 5ac2341f `hstore` columns are always stored
as `Hash` with `String` keys. `ActiveRecord::Store` expected the attribute to
be an instance of `HashWithIndifferentAccess`, which led to the bug.

This is causing every default value in PostreSQL database to being
handled as default function.

Fixes #12581