This reverts commit 3803fcce.

Conflicts:
	activerecord/CHANGELOG.md

It will be deprecated only in 4.0, and removed properly in 4.1.

Move the logic for validation check to the same method, and cache
dependent option in a variable to reuse inside the dependency
configuration methods instead of relying on the options hash.

It has been moved to active_record_deprecated_finders.

Use #to_a instead.

It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.

The code is moved to active_record_deprecated_finders.

Closes #1190

This code is broken (it should say association_scope.uniq_value rather
than options[:uniq]) but the tests still pass.

I think it is designed to uniq-ify associations using finder_sql.
However, I am about to remove that anyway.

This fixes active_record_deprecated_finders.

Improve the derivation of HABTM join table name to take account of nesting.
It now takes the table names of the two models, sorts them lexically and
then joins them, stripping any common prefix from the second table name.

Some examples:

  Top level models
  (Category <=> Product)
  Old: categories_products
  New: categories_products

  Top level models with a global table_name_prefix
  (Category <=> Product)
  Old: site_categories_products
  New: site_categories_products

  Nested models in a module without a table_name_prefix method
  (Admin::Category <=> Admin::Product)
  Old: categories_products
  New: categories_products

  Nested models in a module with a table_name_prefix method
  (Admin::Category <=> Admin::Product)
  Old: categories_products
  New: admin_categories_products

  Nested models in a parent model
  (Catalog::Category <=> Catalog::Product)
  Old: categories_products
  New: catalog_categories_products

  Nested models in different parent models
  (Catalog::Category <=> Content::Page)
  Old: categories_pages
  New: catalog_categories_content_pages

Also as part of this commit the validity checks for HABTM assocations have
been moved to ActiveRecord::Reflection One side effect of this is to move when
the exceptions are raised from the point of declaration to when the association
is built. This is consistant with other association validity checks.

Historically, update_attribute and update_attributes are similar, but
with one big difference: update_attribute does not run validations.
These two methods are really easy to confuse given their similar
names. Therefore, update_attribute is being removed in favor of
update_column.

See the thread on rails-core here:
https://groups.google.com/forum/?fromgroups#!topic/rubyonrails-core/BWPUTK7WvYA

Thanks to Ben Murphy for reporting this

CVE-2012-2661

I found the next issue between CollectionAssociation `delete`
and `destroy`.

    class Person < ActiveRecord::Base
      has_many :pets
    end

    person.pets.destroy(1)
    # => OK, returns the destroyed object

    person.pets.destroy("2")
    # => OK, returns the destroyed object

    person.pets.delete(1)
    # => ActiveRecord::AssociationTypeMismatch

    person.pets.delete("2")
    # => ActiveRecord::AssociationTypeMismatch

Adding support for deleting with a fixnum or string like
`destroy` method.

This reverts commit fa6d921e.

Reason: Not a fan of such massive changes. We usually close such changes
if made to Rails master as a pull request. Following the same principle
here and reverting.

[ci skip]