- Eager loading was not working for the default_scope (class method)
  for 'find' & 'find_by' methods.
- Fixed these by adding a new check 'respond_to?(:default_scope)'.

Instead use .scope_attributes? consistently in ActiveRecord to check whether
there are attributes currently associated with the scope.

Move the implementation of .scope_attributes? and .scope_attributes to
ActiveRecord::Scoping because they don't particularly have to do specifically
with Named scopes and their only dependency, in the case of
.scope_attributes?, and only caller, in the case of .scope_attributes is
contained in Scoping.

Thank you @bquorning

[ci-skip]
Closes rails/rails#14294

This allows the default scope to be built using the current table alias.
Resolves #12770

We are checking this when defining the default scope and raising an
ArgumentError

Calling default_scope without a proc will now raise `ArgumentError`.

current ScopeRegister object.

current_scope and ignore_default_scope locals are brought together under
a registry object.

See #10107.

Update comment to reflect that unscoped works with named scope
even when named scope is using without block form

It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.

Get rid of ActiveModel::Configuration, make better use of
ActiveSupport::Concern + class_attribute, etc.

Don't use this:

    scope :red, where(color: 'red')
    default_scope where(color: 'red')

Use this:

    scope :red, -> { where(color: 'red') }
    default_scope { where(color: 'red') }

The former has numerous issues. It is a common newbie gotcha to do
the following:

    scope :recent, where(published_at: Time.now - 2.weeks)

Or a more subtle variant:

    scope :recent, -> { where(published_at: Time.now - 2.weeks) }
    scope :recent_red, recent.where(color: 'red')

Eager scopes are also very complex to implement within Active
Record, and there are still bugs. For example, the following does
not do what you expect:

    scope :remove_conditions, except(:where)
    where(...).remove_conditions # => still has conditions

The problem: We need to be able to specify configuration in a way that
can be inherited to models that include ActiveRecord::Model. So it is
no longer sufficient to put 'top level' config on ActiveRecord::Base,
but we do want configuration specified on ActiveRecord::Base and
descendants to continue to work.

So we need something like class_attribute that can be defined on a
module but that is inherited when ActiveRecord::Model is included.

The solution: added ActiveModel::Configuration module which provides a
config_attribute macro. It's a bit specific hence I am not putting this
in Active Support or making it a 'public API' at present.