Signed-off-by: NJosé Valim <jose.valim@gmail.com>

* rsim/require_deprecation:
  require ActiveSupport deprecatation file before using deprecate method in database_statements

* rsim/habtm_select_fix:
  Explicitly select * from has_and_belongs_to_many association tables, simplify exists? query

Previous version (after commit 3103296a) was generating wrong SQL for Oracle when calling exists? method on HABTM association.

otherwise when using external ActiveRecord adapters (e.g. Oracle) database_statements might be loaded before active_support/core_ext/module/deprecation which results in NoMethodError (commit 60cf65de added "deprecate" call to database_statements.rb)

Remove undocumented feature from has_one where you could pass false as the second parameter to build_assoc or create_assoc, and the existing associated object would be untouched (the foreign key would not be nullified, and it would not be deleted). If you want behaviour similar to this you can do the following things:

* Use :dependent => :nullify (or don't specify :dependent) if you want to prevent the existing associated object from being deleted
* Use has_many if you actually want multiple associated objects
* Explicitly set the foreign key if, for some reason, you really need to have multiple objects associated with the same has_one. E.g.

    previous = obj.assoc
    obj.create_assoc
    previous.update_attributes(:obj_id => obj.id)

ActiveRecord::Relation#primary_key should return a string, just like ActiveRecord::Base.primary_key does.

Implement deprecated version of AssociationReflection#primary_key_name, which has been renamed to #foreign_key. Also bumping the deprecation_horizon in Active Support to 3.1.

When preloading a belongs_to, the target should still be set (to nil) if there is no foreign key present. And the loaded flag should be set on the association proxy. This then allows us to remove the foreign_key_present? check from BelongsToAssociation#find_target. Also added a test for the same thing on polymorphic associations.

Make Relation#create_with always merge rather than overwrite, not just when merging two relations. If you wish to overwrite, you can do relation.create_with(nil), or for a specific attribute, relation.create_with(:attr => nil).

Let AssociationCollection#find use #scoped to do its finding. Note that I am removing test_polymorphic_has_many_going_through_join_model_with_disabled_include, since this specifies different behaviour for an association than for a regular scope. It seems reasonable to expect scopes and association proxies to behave in roughly the same way rather than having subtle differences.

Fix test_any in relations_test.rb, which was failing when relations_test.rb is run on its own (it passes when the entire suite is run). This is a hacky fix for a problem I didn't quite get to the bottom of, so I'd welcome a better solution...