Column names inserted via `group` have to be qualified with table name.

The focus of this change is to make the API more accessible.
References to method and classes should be linked to make it easy to
navigate around.

This patch makes exzessiv use of `rdoc-ref:` to provide more readable
docs. This makes it possible to document `ActiveRecord::Base#save` even
though the method is within a separate module
`ActiveRecord::Persistence`. The goal here is to bring the API closer to
the actual code that you would write.

This commit only deals with Active Record. The other gems will be
updated accordingly but in different commits. The pass through Active
Record is not completely finished yet. A follow up commit will change
the spots I haven't yet had the time to update.

/cc @fxn

This removes the following warning.
```
activerecord/lib/active_record/relation/calculations.rb:74: warning: `&' interpreted as argument prefix
```

Arguments of `#sum` does not match with other shortcuts methods
(count, average, minimum, and maximum).
This commit fix these two points:

* call `super` with only block arguments
  First argument of `super` method, `Enumerable#sum`, is `identity`
  and first argument of `AR::Calculations#sum` is `column_name`.
  `Enumerable#sum` does not expect `column_name` to be passed.
* Change first argument of `sum` from array arguemnt to single
  argument to match other shortcuts methods. When `sum` accept
  array arguemnt, user can pass multi arguments and an exception is
  raised from `calculate`.

as #uniq will be removed from Rails 5.0 as per the Active Support
exception raised:

ActiveSupport::DeprecationException: DEPRECATION WARNING: uniq is
deprecated and will be removed from Rails 5.0 (use distinct instead).

This is to show users that they can chain `.uniq` and `.pluck` to get
the `DISTINCT column` result. They don't have to do `DISTINCT column`
themselves.

After discussing, we've decided it makes more sense to include it. We're
already forwarding every conflicting method to `to_a`, and there's no
conflation of concerns. `Enumerable` has no mutating methods, and it
just allows us to simplify the code. No existing methods will have a
change in behavior. Un-overridden Enumerable methods will simply
delegate to `each`.

[Sean Griffin & bogdan]

This matches our behavior in other cases where useful enumerable methods
might have a different definition in `Relation`. Wanting to actually
enumerate over the records in this case is completely reasonable, and
wanting `.sum` is reasonable for the same reason it is on `Enumerable`
in the first place.

This allows easier integration with ActiveRecord, such that
AR#pluck will now use Enumerable#pluck if the relation is loaded,
without needing to hit the database.

Documentation is giving an example that can be replaced by a more dry command.
Give a hint that ids can be used instead of pluck(:id).

It is redundant with tests in `eager_loading?`, but for the difference
between `includes_values.present?` and `includes_values.any?`, which
is a difference without a distinction because `false` has no meaning
for `includes`.

[ci skip]

It's finally finished!!!!!!! The reason the Attributes API was kept
private in 4.2 was due to some publicly visible implementation details.
It was previously implemented by overloading `columns` and
`columns_hash`, to make them return column objects which were modified
with the attribute information.

This meant that those methods LIED! We didn't change the database
schema. We changed the attribute information on the class. That is
wrong! It should be the other way around, where schema loading just
calls the attributes API for you. And now it does!

Yes, this means that there is nothing that happens in automatic schema
loading that you couldn't manually do yourself. (There's still some
funky cases where we hit the connection adapter that I need to handle,
before we can turn off automatic schema detection entirely.)

There were a few weird test failures caused by this that had to be
fixed. The main source came from the fact that the attribute methods are
now defined in terms of `attribute_names`, which has a clause like
`return [] unless table_exists?`. I don't *think* this is an issue,
since the only place this caused failures were in a fake adapter which
didn't override `table_exists?`.

Additionally, there were a few cases where tests were failing because a
migration was run, but the model was not reloaded. I'm not sure why
these started failing from this change, I might need to clear an
additional cache in `reload_schema_from_cache`. Again, since this is not
normal usage, and it's expected that `reset_column_information` will be
called after the table is modified, I don't think it's a problem.

Still, test failures that were unrelated to the change are worrying, and
I need to dig into them further.

Finally, I spent a lot of time debugging issues with the mutex used in
`define_attribute_methods`. I think we can just remove that method
entirely, and define the attribute methods *manually* in the call to
`define_attribute`, which would simplify the code *tremendously*.

Ok. now to make this damn thing public, and work on moving it up to
Active Model.

Fixes #18717

`bound_attributes` is now used universally across the board, removing
the need for the conversion layer. These changes are mostly mechanical,
with the exception of the log subscriber. Additional, we had to
implement `hash` on the attribute objects, so they could be used as a
key for query caching.

The bind values can come from four places. `having`, `where`, `joins`,
and `from` when selecting from a subquery that contains binds. These
need to be kept in a specific order, since the clauses will always
appear in that order. Up until recently, they were not.

Additionally, `joins` actually did keep its bind values in a separate
location (presumably because it's the only case that people noticed was
broken). However, this meant that anything accessing just `bind_values`
was broken (which most places were). This is no longer possible, there
is only a single way to access the bind values, and it includes joins in
the proper location. The setter was removed yesterday, so breaking `+=`
cases is not possible.

I'm still not happy that `joins` is putting it's bind values on the
Arel AST, and I'm planning on refactoring it further, but this removes a
ton of bug cases.

This fixed an issue where `having` can only be called after the last
call to `where`, because it messes with the same `bind_values` array.
With this change, the two can be called as many times as needed, in any
order, and the final query will be correct. However, once something
assigns `bind_values`, that stops. This is because we have to move all
of the bind values from the having clause over to the where clause since
we can't differentiate the two, and assignment was likely in the form
of:

`relation.bind_values += other.bind_values`

This will go away once we remove all places that are assigning
`bind_values`, which is next on the list.

While this fixes a bug that was present in at least 4.2 (more likely
present going back as far as 3.0, becoming more likely in 4.1 and later
as we switched to prepared statements in more cases), I don't think this
can be easily backported. The internal changes to `Relation` are
non-trivial, anything that involves modifying the `bind_values` array
would need to change, and I'm not confident that we have sufficient test
coverage of all of those locations (when `having` was called with a hash
that could generate bind values).

[Sean Griffin & anthonynavarre]

MySQL reports the column name as `"MAX(developer_id)"`. PG will report
it as `"max"`

Arel has changed so that `.sum` no longer aliases `SUM(the_column)` to
`sum_id`. This means the type returned by the adapter will be at the key
`"SUM(the_column)"`. Longer term, we should eventually be able to retain
type information from the AR::Base subclasses used in joined queries

The hash is now string-keyed, and [_]reflect_on_association calls `to_s` on the
argument anyway.

Attempting to reduce the number of places that care about the details of
how type casting occurs. We remove the type casting of the primary key
in `JoinDependecy`, rather than encapsulating it. It was originally
added for consistency with
https://github.com/rails/rails/commit/40898c8c19fa04442fc5f8fb5daf3a8bdb9a1e03#diff-06059df8d3dee3101718fb2c01151ad0R211,
but that conditional was later removed in
https://github.com/rails/rails/commit/d7ddaa530fd1b94e22d745cbaf2e8a5a34ee9734.

What is important is that the same row twice will have the same value
for the primary key, which it will.

The column name given by the adapter doesn't include the table
namespace, so going through the hashed version of the result set causes
overridden keys.

Fixes #15649

In some cases there is a difference between the two, we should always
be doing one or the other. For convenience, `type_cast` is still a
private method on type, so new types that do not need different behavior
don't need to implement two methods, but it has been moved to private so
it cannot be used accidentally.

Reflection has a `belongs_to?` method. Instead of checking for
`macro == :belongs_to` throughout the source reuse existing
method.

I also bumped `foreign_key_present?` method onto on line because
the `belongs_to?` makes it shorter than other longer lines in
the same class.

This was previously a hook for a special case related to `serialize`,
which has since been removed.

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

bind parameters we not being propogated to simple subquery calculation
calls. This fixes it

968c581e have fixed the EagerLoadTest, but
not in the correct way.

The problem was when `empty?` or `size` was called on relation. It was
triggering `count(:all)`, which was passing `:all` as the column name to `count`
on Calculations.

On the other hand, the method `calculate` on Calculations was calling
`construct_relation_for_association_calculations` instead of `perform_calculation`,
because `has_include?` was returning `true` since `column_name` was present.

To prevent calling the wrong method to perform the calculation, we have to check
if the `column_name` is present and if it is different from `:all` (which is now used
to correctly do `count` with `select`).

More information here: https://github.com/rails/rails/commit/968c581ea34b5236af14805e6a77913b1cb36238#commitcomment-6006135

This is necessary because Postgresql doesn't play nice with ORDER BY and
no GROUP BY.

Fixes #14621.