`restrict_with_error` message will now respect owner’s human name in any locale [kuboon & Ronak Jangir]

Current implementation has a lot of utility methods that accept
reflection call a lot of methods on it and exit.

E.g. has_counter_cache?(reflection)

It causes confusion and inability to cache result of the method even
through it always returns the same result for the same reflection
object.
It can be done easier without access to the association context
by moving code into reflection itself.

e.g. reflection.has_counter_cache?

Reflection is less complex object than association so moving code there
automatically makes it simplier to understand.

Previously `has_one` and `has_many` associations were using the
`one` and `many` keys respectively. Both of these keys have special
meaning in I18n (they are considered to be pluralizations) so by
renaming them to `has_one` and `has_many` we make the messages more
explicit and most importantly they don't clash with linguistical
systems that need to validate translation keys (and their
pluralizations).

The `:'restrict_dependent_destroy.one'` key should be replaced with
`:'restrict_dependent_destroy.has_one'`, and
`:'restrict_dependent_destroy.many'` with
`:'restrict_dependent_destroy.has_many'`.

[Roque Pinel & Christopher Dell]

Previously has_many associations assumed a counter_cache was to be used
based on the presence of an appropriately named column. This is
inconsistent, since the inverse belongs_to association will not make
this assumption. See issues #19042 #8446.
This commit checks for the presence of the counter_cache key in the
options of either the has_many or belongs_to association as well as
ensuring that the *_count column is present.

The cache name should be converted to a string when given, not compared
as a symbol. This edge case is already adequately covered by our tests,
but was masked by another issue where we were incorrectly updating the
counter cache twice. When paired with a bug where we didn't update the
counter cache because we couldn't find a match with the name, this made
it look like everything was working fine.

Fixes #10865.

When we made sure that the counter gets updated in memory, we only did
it on the has many side. The has many side only does the update if the
belongs to cannot. The belongs to side was updated to update the counter
cache (if it is able). This means that we need to check if the
belongs_to is able to update in memory on the has_many side.

We also found an inconsistency where the reflection names were used to
grab the association which should update the counter cache. Since
reflection names are now strings, this means it was using a different
instance than the one which would have the inverse instance set.

Fixes #18689

[Sean Griffin & anthonynavarre]

Before this commit, returning `false` in an ActiveRecord `before_` callback
such as `before_create` would halt the callback chain.

After this commit, the behavior is deprecated: will still work until
the next release of Rails but will also display a deprecation warning.

The preferred way to halt a callback chain is to explicitly `throw(:abort)`.

We added a comparison to "id", and call to `self.class.primary_key` a
*lot*. We also have performance hits from `&block` all over the place.
We skip the check in a new method, in order to avoid breaking the
behavior of `read_attribute`

WARNING: don't use them! They might change or go away between future beta/RC/
patch releases!

Also added a CHANGELOG entry for this.

Now that we define the macro on the reflection type we no longer
need to check `macro == :what` on each type for `belongs_to?` or
`has_one?` etc. These now default to false unless it's defined
in the reflection class.

Reuse existing belongs_to? method to check macros

We don't need to do `:belongs_to == macro` anymore becasue we
have a `belongs_to?` method. I didn't find this being used
anywhere for `has_one?` or `collection?` since they were already
fixed.

Reliant on https://github.com/rails/rails/pull/15747 but pulled to a
separate PR to reduce noise. `has_many :through` associations have the
undocumented behavior of automatically detecting counter caches.
However, the way in which it does so is inconsistent with counter caches
everywhere else, and doesn't actually work consistently.

As with normal `has_many` associations, the user should specify the
counter cache on the `belongs_to`, if they'd like it updated.

Before, calling `size` would only work if it skipped the cache, and
would return a different result from the cache, but only if:

- The association was previously loaded
- Or you called size previously
- But only if the size was 0 when you called it

This ensures that the counter is appropriately updated in memory.

Fix habtm reflection
Conflicts:
    activerecord/CHANGELOG.md
    activerecord/lib/active_record/counter_cache.rb
    activerecord/lib/active_record/reflection.rb
    activerecord/test/cases/reflection_test.rb

this change was unneccsary as nothing was gained from it

Rename delete_all_records because this name better describes
what the method is doing. We can then remove :all from the
hm:t version and pull out the unoptimized call to load_target
in delete_records and pass it directly.

Refactor delete_count method to only handle delete_all or nullify/nil cases
and not destroy and switch to if/else rather than case statement. This
refactoring allows removal of :all symbol usage.

Refactor by creating two methods delete_all_records and delete_records
to be called by delete_all and delete (or destroy) respectively.
This reduces the number of conditionals required to handle _how_
records get deleted.

The new delete_count method handles how scope is applied to which
delete action.

A delete_all_records method also has to be called in has_many_through
association because of how the methods are chained. This will be
refactored later on.

Apparently we've been using a buggy feature for the past 6 years:

  https://bugs.ruby-lang.org/issues/9593

Fixes #12812
Raise `ActiveRecord::RecordNotDestroyed` when a child marked with
`dependent: destroy` can't be destroyed.

The following code:
```ruby
class Post < ActiveRecord::Base
  has_many :comments, dependent: :destroy
end

class Comment < ActiveRecord::Base
  before_destroy do
    return false
  end
end

post = Post.create!(comments: [Comment.create!])
post.comments = [Comment.create!]
````

would result in a `post` with two `comments`.
With this commit, the same code would raise a `RecordNotDestroyed`
exception, keeping the `post` with the same `comment`.

This reverts commit 9dc8aef0, reversing
changes made to 02e8dae6.

Remove ambiguity with pluralizations and I18n keys used for association restrict_dependent_destroy errors

When removing records from a `has_many` association it used
the `primary_key` defined on the association.

Our test suite didn't fail because on all occurences of `:primary_key`,
the specified column was available in both tables. This prevented the
code from raising an exception but it still behaved badly.

I added a test-case to prevent regressions that failed with:

```
  1) Error:
HasManyAssociationsTest#test_has_many_assignment_with_custom_primary_key:
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: essays.first_name: UPDATE "essays" SET "writer_id" = NULL WHERE "essays"."writer_id" = ? AND "essays"."first_name" IS NULL
```

Commit https://github.com/rails/rails/pull/9668 shows warning
when `delete_all` is invoked with `:dependent` option
`:destroy`.

Unfortunately invoking `Post.destroy_all` invokes
`post.comments.delete_all` as part of `has_many` callbacks.

This commit ensures that instead `post.comments.destroy_all` is
invoked and in the process no warning is generated.

See issue #9567 for details .

This reverts commit 3803fcce.

Conflicts:
	activerecord/CHANGELOG.md

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