Conflicts:
	activerecord/test/cases/query_cache_test.rb

Conflicts:
	activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb

Prepared statements (prepare/execute/close) were being used unnecessarily
when no bind variables were present, and disabling prepared statement using
prepared_statements:false was principally broken. While bind variables were
correctly substituted with prepared_statements:false, the prepared statement
interface was still used, costing an extra two round trips per query.

In addition to making this behavioral change, I also cleaned up the internals
of exec_stmt and exec_without_stmt so that they behave the same (calling log
and constructing the ActiveRecord::Result in the same way).

Moving the check for binds.empty? to exec_query also will mean that several
code paths explicitly calling exec_without_stmt could be cleaned up to once
again call exec_query instead. I have also left the check for binds.empty? in
exec_stmt, since it is not a private method and could be called directly with
an empty binds array. For the sake of clarity in this patch, I have not made
those changes.

= The previous behavior =

When issuing a Foo.find(1) with prepared_statements:true, the bind variable
is present in the prepared query, and execute shows a value passed:

    Connect	root@localhost on rails_test
    Query	SET SQL_AUTO_IS_NULL=0
    Statistics
    Query	SHOW FULL FIELDS FROM `foos`
    Query	SHOW TABLES LIKE 'foos'
    Query	SHOW CREATE TABLE `foos`
    Prepare	SELECT  `foos`.* FROM `foos`  WHERE `foos`.`id` = ? LIMIT 1
    Execute	SELECT  `foos`.* FROM `foos`  WHERE `foos`.`id` = 1 LIMIT 1
    Close stmt
    Quit

When issuing a Foo.find(1) with prepared_statements:false, the bind variable
has already been removed and substituted with the value, but the prepared
statement interface is used anyway:

    Connect	root@localhost on rails_test
    Query	SET SQL_AUTO_IS_NULL=0
    Statistics
    Query	SHOW FULL FIELDS FROM `foos`
    Query	SHOW TABLES LIKE 'foos'
    Query	SHOW CREATE TABLE `foos`
    Prepare	SELECT  `foos`.* FROM `foos`  WHERE `foos`.`id` = 1 LIMIT 1
    Execute	SELECT  `foos`.* FROM `foos`  WHERE `foos`.`id` = 1 LIMIT 1
    Close stmt
    Quit

= With this patch applied =

When issuing a Foo.find(1) with prepared_statements:true, the bind variable
is present in the prepared query, and execute shows a value passed:

    Connect	root@localhost on rails_test
    Query	SET SQL_AUTO_IS_NULL=0
    Statistics
    Query	SHOW FULL FIELDS FROM `foos`
    Query	SHOW TABLES LIKE 'foos'
    Query	SHOW CREATE TABLE `foos`
    Prepare	SELECT  `foos`.* FROM `foos`  WHERE `foos`.`id` = ? LIMIT 1
    Execute	SELECT  `foos`.* FROM `foos`  WHERE `foos`.`id` = 1 LIMIT 1
    Close stmt
    Quit

When issuing a Foo.find(1) with prepared_statements:false, the bind variable
has been removed and substituted with the value, and the query interface is
used instead of the prepared statement interface:

    Connect	root@localhost on rails_test
    Query	SET SQL_AUTO_IS_NULL=0
    Statistics
    Query	SHOW FULL FIELDS FROM `foos`
    Query	SHOW TABLES LIKE 'foos'
    Query	SHOW CREATE TABLE `foos`
    Query	SELECT  `foos`.* FROM `foos`  WHERE `foos`.`id` = 1 LIMIT 1
    Quit

The instructions about configuration covered only rails-specific usage.

Dry up reseting the renamed table after each test.

Also made use of the AR::Base.connection object already
available from AR::MigrationTest#connection.

AddXXXToYYY/RemoveXXXFromYYY migrations are produced with references
statements, for instance

    rails g migration AddReferencesToProducts user:references
supplier:references{polymorphic}

will generate the migration with:

    add_reference :products, :user, index: true
    add_reference :products, :supplier, polymorphic: true, index: true

This reverts commit c47a698d.

Reason: Let's revert pending further discussions

Introduced in 75b340d1

A test was failing due to the way that Relation#inspect causes
association proxies to ignore unsaved records added to the association.

This is fixed by simply calling to_a and letting to_a figure out how to
get the records (which, in the case of associations, takes into account
new records).

I think it is acceptable to do this rather than limiting the query at
the database level:

* It's what we've done in all released Rails versions up to this point
* The goal of the limit is to not flood the console with output - this
  is the problem we're targeting, rather than the actual loading of the
  records from the database
* You probably want to do something with those records later anyway,
  otherwise you wouldn't have built a relation for them.

While it's interesting to have the results array, it can make a console or a webpage freeze if there are a lot of them.
So this limits the number of records displayed in #inspect to 10 and tells how much were effectively found.