Deprecate leaking scope in callback block for association relation

Since #31575, `set_inverse_instance` replaces the foreign key by the
current owner immediately to make it happen when a record is added to
collection association.

But `set_inverse_instance` is not only called when a record is added,
but also when a record is loaded from queries. And also, that loaded
records are not always associated records for some reason (using `or`,
`unscope`, `rewhere`, etc).

It is hard to distinguish whether or not we should invoke
`set_inverse_instance`, but at least we should avoid the undesired
side-effect which was brought from #31575.

Fixes #34108.

Most of the time the table and predicate_builder
passed to Relation.new are exactly the
arel_table and predicate builder of the
given klass. This uses klass.arel_table
and klass.predicate_builder as the defaults,
so we don't have to pass them in most cases.

This does change the signaure of both Relation and
AssocationRelation. Are we ok with that?

This reverts commit 3420a145, reversing
changes made to afb66a5a.

If a parent association was accessed in an `after_find` or
`after_initialize` callback, it would always end up loading the
association, and then immediately overwriting the association we just
loaded. If this occurred in a way that the parent's `current_scope` was
set to eager load the child, this would result in an infinite loop and
eventually overflow the stack.

For records that are created with `.new`, we have a mechanism to
perform an action before the callbacks are run. I've introduced the same
code path for records created with `instantiate`, and updated all code
which sets inverse instances on newly loaded associations to use this
block instead.

Fixes #26320.

Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.

Various behaviors needed by associations (such as creating the through
record) are lost when `where` is called, since we stop having a
`CollectionProxy` and start having an `AssociationRelation` which does
not contain this behavior. I *think* we should be able to rm
`AssociationRelation`, but we have tests saying the changes required to
do that would be bad (Without saying why. Of course. >_>)

Fixes #19073.

Construction of relations can be a hotspot, we don't want to create one
of these in the constructor. This also allows us to do more expensive
things in the predicate builder's constructor, since it's created once
per AR::Base subclass

968c581e have introduced this bug #14744
on Association Relation when the method `empty?` or `size` was called.

Example:
  # Given an author that does have 3 posts, but none of them with the
  # title 'Some Title'
  Author.last.posts.where(title: 'Some Title').size
  # => 3

It was occurring, because the Association Relation had implemented these
methods based on `@association`, this way giving wrong results.

To fix it, was necessary to remove the methods `empty?` and `size` from
Association Relation. It just have to use these methods from Relation.

Example:
  # Given an author that does have 3 posts, but none of them with the
  # title 'Some Title'
  Author.last.posts.where(title: 'Some Title').size
  # => 0
  # Now it will return the correct value.

Fixes #14744.

consistent.

Suppose Man has_many interests, and inverse_of is used.

Man.first.interests.first.man will correctly execute two queries,
avoiding the need for a third query when Interest#man is called. This is
because CollectionAssociation#first calls set_inverse_instance.

However Man.first.interests.where("1=1").first.man will execute three
queries, even though this is obviously a subset of the records in the
association.

This is because calling where("1=1") spawns a new Relation object from
the CollectionProxy object, and the Relation has no knowledge of the
association, so it cannot set the inverse instance.

This commit solves the problem by making relations spawned from
CollectionProxies return a new Relation subclass called
AssociationRelation, which does know about associations. Records loaded
from this class will get the inverse instance set properly.

Fixes #5717.

Live commit from La Conf! ✨