Before 29874cc4 the order values
would be deduplicated when the SQL query is generated, but now
it has to be eager.

Directly `klass.new` is clear enough than factory methods.

In Active Record internal, `arel_table` is not directly used but
`arel_attribute` is used, since `arel_table` doesn't normalize an
attribute name as a string, and doesn't resolve attribute aliases.

For the above reason, `arel_attribute` should be used rather than
`arel_table`, but most people directly use `arel_table`, both
`arel_table` and `arel_attribute` are private API though.

Although I'd not recommend using private API, `arel_table` is actually
widely used, and it is also problematic for unscopeable queries and
hash-like relation merging friendly, as I explained at #39863.

To resolve the issue, this change moves Arel attribute normalization
(attribute name as a string, and attribute alias resolution) into
`arel_table`.

`PredicateBuilder.references` and `PredicateBuilder#build_from_hash`
does similar processing and both requires stringify keys for passed hash
argument. This consolidates stringify keys to avoid extra string
allocation in `PredicateBuilder`.

I'd not prefer to allocate its less interested object, it doesn't
improve readability, and make code slower.

It is no longer only for `or` but also for `and`.

I often hit the inconvenience (recently in #39558).

`and`/`or` are focused to combine where-like clauses, so we often use
one-time relation which has only where clause. But if the receiver has
values other than where clause (e.g. `order`, `select`, `includes`,
etc), `and`/`or` will raise structurally incompatible error.

Since it is harder to predict the receiver has which values other than
where clause before doing `and`/`or`, that restriction is a little
annoying to me.

So I'd like to relax that restriction, at least unless other values are
set explicitly for multiple values.

As described at #39328, `relation.merge` behaves inspired as Hash-like
merge for where clause. In other words, currently there is no official
way to intersect the result by both relation conditions (i.e. there is
no official way to maintain both relation conditions).

To resolve that issue, I'd like to support a way to intersect relations
as `relation.and`.

```ruby
david_and_mary = Author.where(id: [david, mary])
mary_and_bob   = Author.where(id: [mary, bob]) # => [bob]

david_and_mary.merge(mary_and_bob) # => [mary, bob]

david_and_mary.and(mary_and_bob) # => [mary]
david_and_mary.or(mary_and_bob)  # => [david, mary, bob]
```

Fixes #39232.

Related to #39292.

Fixes #39460.

Follow up to #39415.

An error occurs when you pass a relation with SQL comments to the `or` method.

```ruby
class Post
  scope :active, -> { where(active: true).annotate("active posts") }
end

Post.where("created_at > ?", Time.current.beginning_of_month)
  .or(Post.active)
```

In order to work without `ArgumentError`, it changes the `or` method to ignore
SQL comments in the argument.

Ref: https://github.com/rails/rails/pull/38145#discussion_r363024376

ff45b9e9 had removed that limitation for `or`.

[ci skip]

`joins_values` is already `compact_blank!`ed, so `blank?` check is
entirely redundant.

We've learned that `merge` causes duplicated multiple values easily, so
if we missed to deduplicate the values, it will cause weird behavior
like #38052, #39171.

I've investigated the deduplication for the values, at least that had
existed since Rails 3.0.

https://github.com/rails/rails/commit/bed9179aa1496f6d28891cf515af0d7e515ebbab

Aggregations with group by multiple fields was introduced at Rails 3.1,
but we missed the deduplication for the aggregation result, unlike the
generated SQL.

https://github.com/rails/rails/commit/a5cdf0b9eb860c4370ae5fde231e1b61f71b6b65

While the investigation, I've found that `annotate` is also missed the
deduplication.

I don't suppose this weird behavior is intended for both.

So I'd like to deprecate the duplicated behavior in Rails 6.1, and will
be deduplicated all multiple values in Rails 6.2.

To migrate to Rails 6.2's behavior, use `uniq!(:group)` to deduplicate
group fields.

```ruby
accounts = Account.group(:firm_id)

# duplicated group fields, deprecated.
accounts.merge(accounts.where.not(credit_limit: nil)).sum(:credit_limit)
# => {
#   [1, 1] => 50,
#   [2, 2] => 60
# }

# use `uniq!(:group)` to deduplicate group fields.
accounts.merge(accounts.where.not(credit_limit: nil)).uniq!(:group).sum(:credit_limit)
# => {
#   1 => 50,
#   2 => 60
# }
```

Currently the query values normalization for multiple values is missing
some parts.

Some values are flatten, but others are not flatten.
Some values are compact, but others are not compact.
some values are compact_blank, but others are not compact_blank.

Originally all multiple values should be flatten and compact_blank
before `build_arel`, if it is not ensured which multiple values are
normalized or not, we need to normalize it again carefully and
conservatively in `build_arel`.

To unify the query values normalization for multiple values, ensure the
normalization in `check_if_method_has_arguments!` since all multiple
values should be checked by the method.

Related #39236.

`relation.merge` method sometimes replaces mergee side condition, but
sometimes maintain both conditions unless `relation.rewhere` is used.

It is very hard to predict merging result whether mergee side condition
will be replaced or not.

One existing way is to use `relation.rewhere` for merger side relation,
but it is also hard to predict a relation will be used for `merge` in
advance, except one-time relation for `merge`.

To address that issue, I propose to support merging option `:rewhere`,
to allow mergee side condition to be replaced exactly.

That option will allow non-`rewhere` relation behaves as `rewhere`d
relation.

```ruby
david_and_mary = Author.where(id: david.id..mary.id)

# both conflict conditions exists
david_and_mary.merge(Author.where(id: bob)) # => []

# mergee side condition is replaced by rewhere
david_and_mary.merge(Author.rewhere(id: bob)) # => [bob]

# mergee side condition is replaced by rewhere option
david_and_mary.merge(Author.where(id: bob), rewhere: true) # => [bob]
```

#38354 is caused by #36304, to fix invalid joins order for through
associations.

Actually passing Arel joins to `joins` is not officially supported
unlike string joins, and also Arel joins could be easily converted to
string joins by `to_sql`. But I'd not intend to break existing apps
without deprecation cycle, so I've changed to mark only implicit joins
as leading joins, to maintain the original joins order for user supplied
Arel joins.

Fixes #38354.

#38597 is caused by #35864.

To reproduce this issue, at least it is required four different models
and three left joins from different relations.

When merging a relation from different model, new stashed (left) joins
should be placed before existing stashed joins, but #35864 had broken
that expectation if left joins are stashed multiple times.

This fixes that stashed left joins order as expected.

Fixes #38597.

That issues are caused by using only the model's cast types on the
relation.
To fix that issues, use the attribute's type caster takes precedence
over the model's cast types on the relation.

Fixes #35232.
Fixes #36042.
Fixes #37484.

Association look up requires association class is loaded especially for
through association. Just apply that look up only in aggregation column
for now.

Follow up of #39255.

Previously aggregation functions only use the model's attribute types on
the relation for type cast, this will be looking up association's
attribute and type caster if a column name is table name qualified.

Fixes #39248.

Actually that result is odd and hard to predictable result to me, but we
should not change the public behavior without deprecation cycle.

I had not intended to break any apps, so I've restored the behavior.

Fixes #39171.

It is possible to unscope only the column in the specified table.

```ruby
posts = Post.joins(:comments).group(:"posts.hidden")
posts = posts.where("posts.hidden": false, "comments.hidden": false)

posts.count
# => { false => 10 }

# unscope both hidden columns
posts.unscope(where: :hidden).count
# => { false => 11, true => 1 }

# unscope only comments.hidden column
posts.unscope(where: :"comments.hidden").count
# => { false => 11 }
```
Co-authored-by: NSlava Korolev <korolvs@gmail.com>

```ruby
steve = Person.find_by(name: "Steve")
david = Author.find_by(name: "David")

relation = Essay.where(writer: steve)

# Before
relation.rewhere(writer: david).to_a # => []

# After
relation.rewhere(writer: david).to_a # => [david]
```

For now `rewhere` only works for truly column names, doesn't work for
alias attributes, nested conditions, associations.

To fix that, need to build new where clause first, and then get
attribute names from new where clause.

I wrote this shell script to find words from the Rails repo,
so I can paste them into https://www.horsepaste.com/ for
the [codenames game](https://en.m.wikipedia.org/wiki/Codenames_(board_game)).

```bash
git grep -Il '' | \
  grep -v -E "CHANGELOG|Gemfile|gemspec|package\.json|yarn\.lock" | \
  xargs cat | \
  sed '/[^ ]\{10,\}/d' | \
  sed 's/\([A-Z]\)/ \1/g' | \
  tr 'A-Z' 'a-z' | \
  tr -c -s 'a-z' '\n' | \
  sed '/^.\{0,3\}$/d' | \
  sort | \
  uniq | \
  tr '\n' ',' | \
  pbcopy
```

You can see the result in https://www.horsepaste.com/rails-fixed.
Click "Next game" to cycle the words.

Found some typos in the codebase from this 😂

This is how I generated the list of possible typos:

```bash
git grep -Il '' | \
  grep -v -E "CHANGELOG|Gemfile|gemspec|package\.json|yarn\.lock" | \
  xargs cat | \
  sed '/[^ ]\{10,\}/d' | \
  sed 's/\([A-Z]\)/ \1/g' | \
  tr 'A-Z' 'a-z' | \
  tr -c -s 'a-z' '\n' | \
  sed '/^.\{0,3\}$/d' | \
  sort | \
  uniq | \
  aspell --ignore-case list
```

I manually reviewed the list and made the corrections
in this commit. The rest on the list are either:

* Bugs in my script: it split things like "doesn't" into
  "doesn" and "t", if find things like `#ffffff` and
  extracts "ffffff" as a word, etc
* British spelling: honour, optimised
* Foreign words: bonjour, espanol
* Names: nginx, hanekawa
* Technical words: mutex, xhtml
* Portmanteau words: autosave, nodelist
* Invented words: camelize, coachee
* Shortened words: attrs, repo
* Deliberate typos: hllo, hillo (used in code examples, etc)
* Lorem ipsum words: arcu, euismod

This is the [output](https://gist.github.com/chancancode/eb0b573d667dc31906f33f1fb0b22313)
of the script *after* fixing the typos included in this
commit. In theory, someone can run that command again in
the future and compare the output to catch new typos (i.e.
using my list to filter out known typos).

Limitations: the aspell dictionary could be wrong, I
could have miss things, and my script ignores words that
are less than 3 characters or longer than 10 characters.

This is done because concerns of respective steps can be separated,
which in turns leads to easier walkthrough and verbosity. Also
stretching a function to large horizontal bounds doesn't looks good.

Follow-up of ac9b11a8.

Add `#strict_loading` to any record to prevent lazy loading of associations.
`strict_loading` will cascade down from the parent record to all the
associations to help you catch any places where you may want to use
`preload` instead of lazy loading. This is useful for preventing N+1's.
Co-authored-by: NAaron Patterson <aaron.patterson@gmail.com>