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.

`attr.name` is already normalized as a string and alias resolved.

Ref #39881.

Use `arel_table` directly instead.

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`.

This reverts commit b8064500, reversing
changes made to 8714b359.

Reason: This is not approved from the core team yet...

`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`.

```ruby
posts = Post.order(:id)

posts.where("id >": 9).pluck(:id)  # => [10, 11]
posts.where("id >=": 9).pluck(:id) # => [9, 10, 11]
posts.where("id <": 3).pluck(:id)  # => [1, 2]
posts.where("id <=": 3).pluck(:id) # => [1, 2, 3]
```

From type casting and table/column name resolution's point of view,
`where("create_at >=": time)` is better alternative than `where("create_at >= ?", time)`.

```ruby
class Post < ActiveRecord::Base
  attribute :created_at, :datetime, precision: 3
end

time = Time.now.utc # => 2020-06-24 10:11:12.123456 UTC

Post.create!(created_at: time) # => #<Post id: 1, created_at: "2020-06-24 10:11:12.123000">

# SELECT `posts`.* FROM `posts` WHERE (created_at >= '2020-06-24 10:11:12.123456')
Post.where("created_at >= ?", time) # => []

# SELECT `posts`.* FROM `posts` WHERE `posts`.`created_at` >= '2020-06-24 10:11:12.123000'
Post.where("created_at >=": time) # => [#<Post id: 1, created_at: "2020-06-24 10:11:12.123000">]
```

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`.

To be honest, it is hardly worth having a dedicated method for
`where_sql`, since it is a reduced version of `to_sql`.

I've left it for now, but just made it more few code (used `to_sql`).

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.

A relation has a predicate builder, so if a predicate handler which is
referenced by a legacy predicate builder is removed in the new code,
`Marshal.load(legacy_relation.dump)` will fail due to referencing
undefined constant.

I've restored no-op `BaseHandler` constant alias to make cache rotation
easier during Rails 6.1.

Fixes #39601.

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.

Extra predicate handler for just one line preprocess is too expensive.

```ruby
ActiveRecord::Schema.define do
  create_table :users, force: true do |t|
  end
end

class User < ActiveRecord::Base
end

predicate_builder = User.predicate_builder

attr = User.arel_attribute(:id)
user = User.create!
user_id = user.id

Benchmark.ips do |x|
  x.report("build:user") { predicate_builder.build(attr, user) }
  x.report("build:user_id") { predicate_builder.build(attr, user_id) }
end
```

Before:

```
Warming up --------------------------------------
          build:user    11.626k i/100ms
       build:user_id    23.314k i/100ms
Calculating -------------------------------------
          build:user    114.151k (± 2.0%) i/s -    581.300k in   5.094468s
       build:user_id    226.420k (± 2.3%) i/s -      1.142M in   5.048205s
```

After:

```
Warming up --------------------------------------
          build:user    21.484k i/100ms
       build:user_id    24.307k i/100ms
Calculating -------------------------------------
          build:user    210.207k (± 1.8%) i/s -      1.053M in   5.009623s
       build:user_id    238.276k (± 2.1%) i/s -      1.215M in   5.102951s
```

Related to #39250 and #39236.

The purpose of the change here is to unify inconsistent behavior on the
merging.

For now, mergee side condition is replaced by merger side condition only
if both arel nodes are Equality or In clauses.

In other words, if mergee side condition is not Equality or In clauses
(e.g. `between`, `or`, `gt`, `lt`, etc), those conditions will be kept
even on the same column.

This behavior is harder to predict unless people are familiar with the
merging behavior.

Originally I suppose this behavior is just an implementation issue
rather than an intended one, since `unscope` and `rewhere`, which were
introduced later than `merge`, works more consistently.

Since most of the conditions are usually Equality and In clauses, I
don't suppose most people have encountered this merging issue, but I'd
like to deprecate the inconsistent behavior and will completely unify
that to improve a future UX.

```ruby
# Rails 6.1 (IN clause is replaced by merger side equality condition)
Author.where(id: [david.id, mary.id]).merge(Author.where(id: bob)) # => [bob]

# Rails 6.1 (both conflict conditions exists, deprecated)
Author.where(id: david.id..mary.id).merge(Author.where(id: bob)) # => []

# Rails 6.1 with rewhere to migrate to Rails 6.2's behavior
Author.where(id: david.id..mary.id).merge(Author.where(id: bob), rewhere: true) # => [bob]

# Rails 6.2 (same behavior with IN clause, mergee side condition is consistently replaced)
Author.where(id: [david.id, mary.id]).merge(Author.where(id: bob)) # => [bob]
Author.where(id: david.id..mary.id).merge(Author.where(id: bob)) # => [bob]
```

If association column names are defined as a symbol, association access
will cause `Symbol#to_s` each time since attributes and columns hash
keys are a string.

To avoid that extra `Symbol#to_s` allocation, ensure column names on
reflection as a string.

Related to 7d4cc56e.

Related to #39292.

Fixes #39460.

This makes `merge rewhere: true` follow the original `merge`'s behavior.

Follow up to #39415.

Related to #7380 and #7392.

`merge` allows to overwrite non-attribute nodes by #7392, so
`merge(..., rewhere: true)` should also have the same ability, to
migrate from the half-baked current behavior to entirely consistent new
behavior.

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
# }
```

Related to #39328, #39358.

For now, `merge` cannot override non-equality clauses, so non-equality
clauses will easily be duplicated by `merge`.

This deduplicates redundant same clauses in `merge`.

If source/through scope references other tables in where/order, we
should explicitly maintain joins in the scope, otherwise association
queries will fail with referenced unknown column.

Fixes #33525.