This class cares far too much about the internals of other parts of
Active Record. This is an attempt to break out a meaningful object which
represents the needs of the predicate builder. I'm not fully satisfied
with the name, but the general concept is an object which represents a
table, the associations to/from that table, and the types associated
with it. Many of these exist at the `ActiveRecord::Base` class level,
not as properties of the table itself, hence the need for another
object. Currently it provides these by holding a reference to the class,
but that will likely change in the future. This allows the predicate
builder to remain wholy concerned with building predicates.

/cc @mrgilman

I'm attempting to remove `klass` as a dependency of the predicate
builder, in favor of an object that better represents what we're using
it for. The only part of this which doesn't fit nicely into that picture
is the check for an association being polymorphic. Since I'm not yet
sure what that is going to look like, I've moved this logic into another
class in an attempt to separate things that will change from things that
won't.

This reduces the number of places which will need to care about single
value or range specific logic as we introduce type casting. The array
handler is only responsible for producing `in` statements.

/cc @mrgilman

[Sean Griffin & Melanie Gilman]

This will allow us to pass the predicate builder into the constructor of
these handlers. The procs had to be changed to objects, because the
`PredicateBuilder` needs to be marshalable. If we ever decide to make
`register_handler` part of the public API, we should come up with a
better solution which allows procs.

/cc @mrgilman

[Sean Griffin & Melanie Gilman]

We're accidentally documenting `PredicateBuilder` and `ArrayHandler`
since there's a constant which is missing `# :nodoc:`

Construction of relations can be a hotspot, we don't want to create one
of these in the constructor. This also allows us to do more expensive
things in the predicate builder's constructor, since it's created once
per AR::Base subclass

I find that `Specifies the starting point for the batch processing.`
does not give enough information for me to understand what this
parameter actually does.

Users should pass strings to queries instead of classes

Clarify that batching methods can be used with any orderable type primary key, not just integer ones, as per @a58cafeb

This ensures that we're handling all forms of nested tables the same way.

We're aware that the `convert_dot_notation_to_hash` method will cause a
performance hit, and we intend to come back to it once we've refactored some of
the surrounding code.

[Melissa Xie & Melanie Gilman]

This commit fixes the following case.

    User.where(User.arel_table[:created_at].lteq(1.year.ago)).unscope(where :created_at)

`where_sql` now requires that we pass it an engine. None of the manager
classes take an engine in their constructor.

We never actually make use of it on the table, since we're constructing
the select manager manually. It looks like if we ever actually were
grabbing it from the table, we're grossly misusing it since it's meant
to vary by AR class.

Its existence on `Arel::Table` appears to be purely for convenience
methods that are never used outside of tests. However, in production
code it just complicates construction of the tables on the rails side,
and the plan is to remove it from `Arel::Table` entirely. I'm not
convinced it needs to live on `SelectManager`, etc either.

on the joined assoiciation

Oh hey, we got to remove some code because of that!

Arel handles this for us automatically. Updated tests, as BindParam is
no longer a subclass of SqlLiteral. We should remove the second argument
to substitute_at entirely, as it's no longer used

We should not behave differently just because a class has a default
scope.

Arel specifically handles `SelectManager`, with the same logic we're
currently performing. The AST is `Enumerable`, which Arel looks for
separately now.

We need to re-order the bind parameters since the AST returned by the
relation will have the where statement as the first bp, which breaks on
PG.

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

In practical terms, this allows serialized columns and tz aware columns
to be used in wheres that go through joins, where they previously would
not behave correctly. Internally, this removes 1/3 of the cases where we
rely on Arel to perform type casting for us.

There were two non-obvious changes required for this. `update_all` on
relation was merging its bind values with arel's in the wrong order.
Additionally, through associations were assuming there would be no bind
parameters in the preloader (presumably because the where would always
be part of a join)

[Melanie Gilman & Sean Griffin]

We end up re-ordering them either way when we construct the Arel AST (in order
to deal with rewhere, etc), so we shouldn't bother giving it a number in the
first place beforehand.

Sufficiently large integers cause `find` and `find_by` to raise
`StatementInvalid` instead of `RecordNotFound` or just returning `nil`.
Given that we can't cast to `nil` for `Integer` like we would with junk
data for other types, we raise a `RangeError` instead, and rescue in
places where it would be highly unexpected to get an exception from
casting.

Fixes #17380

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

Passing ranges to `#in` has been deprecated in Arel.

The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.

Heredocs have better readability, and with `squish` we can still
produce a single line.

This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.

The value methods will default to an empty array for us automatically

The change to accessing keys directly was originally added to allow
`merge` to take a hash. The implementation of `HashMerger` no longer
requires us to be doing so. Accessing the values directly makes it
impossible to change internal storage details, even if shim methods are
added temporarily

This commit removes the duplication of the error message:

> Couldn't find #{@klass.name} with [#{arel.where_sql}]

introduced in #15791 by adding a private method `find_nth!` that
deals with all the method like `first!` and `second!`.