Moves the configs_for and DatabaseConfig struct into it's own file. I
was considering doing this in a future refactoring but our set up forced
me to move it now. You see there are `mattr_accessor`'s on the Core
module that have default settings. For example the `schema_format`
defaults to Ruby. So if I call `configs_for` or any methods in the Core
module it will reset the `schema_format` to `:ruby`. By moving it to
it's own class we can keep the logic contained and avoid this
unfortunate issue.

The second change here does a double loop over the yaml files. Bear with
me...

Our tests dictate that we need to load an environment before our rake
tasks because we could have something in an environment that the
database.yml depends on. There are side-effects to this and I think
there's a deeper bug that needs to be fixed but that's for another
issue. The gist of the problem is when I was creating the dynamic rake
tasks if the yaml that that rake task is calling evaluates code (like
erb) that calls the environment configs the code will blow up because
the environment is not loaded yet.

To avoid this issue we added a new method that simply loads the yaml and
does not evaluate the erb or anything in it. We then use that yaml to
create the task name. Inside the task name we can then call
`load_config` and load the real config to actually call the code
internal to the task. I admit, this is gross, but refactoring can't all
be pretty all the time and I'm working hard with `@tenderlove` to
refactor much more of this code to get to a better place re connection
management and rake tasks.

Passing around and parsing hashes is easy if you know that it's a two
tier config and each key will be named after the environment and each
value will be the config for that environment key.

This falls apart pretty quickly with three-tier configs. We have no idea
what the second tier will be named (we know the first is primary but we
don't know the second), we have no easy way of figuring out
how deep a hash we have without iterating over it, and we'd have to do
this a lot throughout the code since it breaks all of Active Record's
assumptions regarding configurations.

These methods allow us to pass around objects instead. This will allow
us to more easily parse the configs for the rake tasks. Evenually I'd
like to replace the Active Record connection management that passes
around config hashes to use these methods as well but that's much
farther down the road.

`walk_configs` takes an environment, specification name, and a config
and turns them into DatabaseConfig struct objects so we can ask the
configs questions like:

```
db_config.spec_name
=> animals

db_config.env_name
=> development

db_config.config
{ :adapter => mysql etc }
```

`db_configs` loops through all given configurations and returns an array
of DatabaseConfig structs for each config in the yaml file.

and lastly `configs_for` takes an environment and either returns the
spec name and config if a block is given or returns an array of
DatabaseConfig structs just for the given environment.

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 new ActiveRecord configuration option allows you to easily
pinpoint what line of application code is triggering SQL queries in the
development log by appending below each SQL statement log the line of
Ruby code that triggered it.

It’s useful with N+1 issues, and to locate stray queries.

By default this new option ignores Rails and Ruby code in order to
surface only callers from your application Ruby code or your gems.

It is enabled on newly generated Rails 5.2 applications and can be
enabled on existing Rails applications:

```ruby
Rails.application.configure do
  # ...
  config.active_record.verbose_query_logs = true
end
```

The `rails app:upgrade` task will also add it to
`config/development.rb`.

This feature purposely avoids coupling with
ActiveSupport::BacktraceCleaner since ActiveRecord can be used without
ActiveRecord. This decision can be reverted in the future to allow more
configurable backtraces (the exclusion of gem callers for example).

These extra `spawn` are called via `klass.all` and `klass.all` is called
everywhere in the internal. Avoiding the extra `spawn` makes` klass.all`
30% faster for STI classes.

https://gist.github.com/kamipo/684d03817a8115848cec8e8b079560b7

```
Warming up --------------------------------------
       fast relation     4.410k i/100ms
       slow relation     3.334k i/100ms
Calculating -------------------------------------
       fast relation     47.373k (± 5.2%) i/s -    238.140k in   5.041836s
       slow relation     35.757k (±15.9%) i/s -    176.702k in   5.104625s

Comparison:
       fast relation:    47373.2 i/s
       slow relation:    35756.7 i/s - 1.32x  slower
```

This comment was added at 97849deb, but `AssociationProxy` and
`test_triple_equality` was removed at 1644663b. Currently the `===` is
used for `test_decorated_polymorphic_where` that added at #11945.
So I updated "association proxies" to "decorated models".

And also, currently `Core::ClassMethods` appears in the doc.

http://api.rubyonrails.org/classes/ActiveRecord/Core/ClassMethods.html

But it looks like that the methods in the module is not public API.
So I also added `# :nodoc:` to the module.

Statement caches are used as a concurrent map. It will more clarify to
using `Concurrent::Map`.

Actually `StatementCache#execute` is always passed the same klass that
the owner klass of the connection when the statement cache is created.
So passing `klass` to `StatementCache.new` will make more DRY.

`StatementCache` doesn't support range conditions. So we need to through
the args to `FinderMethods#find_by` if range value is passed.

`arel_engine` is only used in `raise_record_not_found_exception!` to use
`engine.connection` (and `connection.visitor`) in `arel.where_sql`.

https://github.com/rails/arel/blob/v8.0.0/lib/arel/select_manager.rb#L183

But `klass.connection` will work as expected even if not using
`arel_engine` (described by `test_connection`). So `arel_engine` is no
longer needed.

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

This was added in c24c8852, removed in
b89ffe7f, and then (unintentionally?)
reintroduced in 2d7ae1b0.

`type_condition` should be overwritten by `create_with_value`. So `type`
in `create_with_value` should be a string because `where_values_hash`
keys are converted to string.

Fixes #27600.

Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby

The alternative of #26213.

Currently `find_by` and `where` with AR object return inconsistent
result. This is caused by statement cache does not support AR object.
Passing to finder method to fix the issue.

Fixes #26210.

find and exists?

- After https://github.com/rails/rails/commit/64e5b897ac944a05a33275e3828a3d4047a6b457,
  only :GeneratedAssociationMethods was remaining to be marked as
  private constant, so marked it as well.
- Before:
        >> User.constants(false)
        => [:GeneratedAssociationMethods]
- After:
        >> User.constants(false)
        => []

Raise `ActiveRecord::RangeError` when values that executed are out of range.

If the call to `.define_attribute_methods` actually ends up loading the
schema (*very* hard to do, as it requires the object being created
without `allocate` having been called, but it can be done by manually
calling `initialize` from inside `marshal_load` if you're crazy), the
value of `_default_attributes` will change from that call.

This is not as good a solution as actually hashing both values, but Ruby
doesn't expose that capability other than allocating the array. Unless we were
to do something silly like have a thread local array that is re-used, I don't
see any other way to do this without allocation. This solution may not be
perfect, but it should reasonably avoid collisions to the extent that we need.

The fact that this only includes column names is an oversight.

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.

Rails dropped Ruby 1.9 support, but this comment still true.

A few have been left for aesthetic reasons, but have made a pass
and removed most of them.

Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.

Some case expressions remain, need to think about those ones.