This is similar to #first_or_create, but slightly different and a nicer
API. See the CHANGELOG/docs in the commit.

Fixes #7853

This is a cleaner version of #6916.

Closes #3165.

This is a real fix (as compared to the band-aid in b127d86c), which uses
the recently-added equality methods for ARel nodes. It has the side
benefit of simplifying the merge code a bit.

This is at best a band-aid for a more proper fix, since it won't truly
handle the removal of the previous equality condition of these other
nodes. I'm planning to put in some work on ARel toward supporting that
goal.

Related: rails/arel#130, ernie/squeel#153, ernie/squeel#156

On reflection, it seems like a bit of a weird method to have on
ActiveRecord::Base, and it shouldn't be needed most of the time anyway.

This method explicitly loads the records and then returns `self`.

Rather than deciding between "do I want an array or a relation?",
most people are actually asking themselves "do I want to eager load
or lazy load?" Therefore, this method provides a way to explicitly
eager-load without having to switch from a `Relation` to an array.

Example:

    @posts = Post.where(published: true).load

    User.order("name asc").order("created_at desc")
    # SELECT * FROM users ORDER BY created_at desc, name asc

This also affects order defined in `default_scope` or any kind of associations.

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

The code is moved to active_record_deprecated_finders.

Previously it returned an Array.

If you want an array, call e.g. `Post.to_a` rather than `Post.all`. This
is more explicit.

In most cases this should not break existing code, since
Relations use method_missing to delegate unknown methods to #to_a
anyway.

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.

The reason for removing the previous implementation of `#inspect` was
that it hid from you that you were dealing with a `Relation` rather than
an `Array`.

But it is still useful to be able to see the records, particularly if you're
writing something like the following in tests:

    assert_equal [foo], Post.where(:bar)

If the assertion fails, you want to see what records were actually
loaded.

So this implementation makes it clear that you've got a `Relation`, but
also shows your records.

now we can invoke previously added scope extension methods

Record.from("(#{sub_query.to_sql})")    -> Record.from(sub_query)
Record.from("(#{sub_query.to_sql}) a")  -> Record.from(sub_query, :a)

Revert "Merge pull request #5494 from armstrjare/active_record_relation_keep_association_join_context_on_merge"

This reverts commit dcd04e76, reversing
changes made to 58a49875.

So a NullRelation (Relation#none) is chainable with database methods.

The #relation method gets called in four places and the return value was instantly cloned in three of them. The only place that did not clone was ActiveRecord::Scoping::Default::ClassMethods#unscoped. This introduced a bug described in #5667 and should really clone the relation, too. This means all four places would clone the relation, so it doesn't make a lot of sense caching it in the first place.

The four places with calls to relations are:

activerecord/lib/active_record/scoping/default.rb:110:in `block in build_default_scope'"
activerecord/lib/active_record/scoping/default.rb:42:in `unscoped'"
activerecord/lib/active_record/scoping/named.rb:38:in `scoped'"
activerecord/lib/active_record/scoping/named.rb:52:in `scope_attributes'"