Fixes a bug that can occur when ActiveJob tries to access ActiveRecord.

Specifically, I had an Active Job process fail on Sidekiq with this error:

```
ActiveJob::DeserializationError: Error while trying to deserialize arguments:
uninitialized constant ActiveRecord::Core::ClassMethods::TableMetadata
Did you mean? ActiveRecord::TableMetadata
```

raised by these lines of code:

```
[GEM_ROOT]/gems/activerecord-5.0.0.1/lib/active_record/core.rb:300 :in `table_metadata`
298
299       def table_metadata # :nodoc:
300         TableMetadata.new(self, arel_table)
301       end
302     end
[GEM_ROOT]/gems/activerecord-5.0.0.1/lib/active_record/core.rb:273 :in `predicate_builder`
[GEM_ROOT]/gems/activerecord-5.0.0.1/lib/active_record/core.rb:290 :in `relation`
```

The problem seems to be that, inside ActiveRecord::Core, the `TableMetadata`
class has not been loaded and, therefore, Rails tries to access the constant
`ActiveRecord::Core::ClassMethods::TableMetadata` which does not exist.

Eager loading `ActiveRecord::TableMetadata` should fix the issue.

@rafaelfranca -- see our Campfire discussion

This was used to switch the output colour between log lines, but now the
output colour is based on the type of statement being logged instead.

`find_nth` is protected method, therefore `offset` has not been passed
anywhere. `find_nth_with_limit_and_offset` is unnecessary anymore
because `offset` has not been passed.

`ActiveSupport::TestCase` was replaced `ActiveRecord::TestCase` in #26150.
But this docs is for rails apps per se, it should be `ActiveSupport::TestCase`.

See https://github.com/rails/rails/pull/26150#discussion_r74710989.

Fixes #26122

since it affects another test `ReflectionTest#test_read_attribute_names`

Address #26099

Thinking .. relative to files is not natural, we are used
to think "parent of a directory", and we have __dir__
nowadays.

If you call `remove_index` with wrong options, say a type, like I did,
you get:

```
== 20160810072541 RemoveUniqueIndexOnGoals: migrating =========================
-- remove_index(:goal, {:coulmn=>:kid_id, :unique=>true})
rails aborted!
StandardError: An error has occurred, this and all later migrations canceled:

undefined method `ArgumentError' for #<ActiveRecord::ConnectionAdapters::PostgreSQLAdapter:0x007fb7dec91b28>
```

What happened is that I mistyped column (coulmn) and got a
`NoMethodError`, because of a missing comma during the raise. This made
Ruby think we're calling the method `ArgumentError`.

Hash syntax auto-correcting breaks alignments. 411ccbda

also test `ROWNUM <=` for Oracle 11g or older version of Oracle and Oracle visitor
Oracle 12c database and Arel Oracle12 visitor supports better top N query.

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.

This method is not touched from outside.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

Passing arel node with splat binds for `where` was introduced at #22877
for uniqueness validator supports prepared statement. But I'd not like
to introduce the following usage:

```ruby
  Foo.where(arel, *binds)
```

I'd like to revert this internal usage.

A `value` is only used for checking `value.nil?`. It is unnecessary if
immediately return when `value.nil?`.

So this bug is kinda funky. The code path is basically "if we weren't passed an
instance of the class we compose to, and we have a converter, call that".
Ignoring the hash case for a moment, everything after that was roughly intended
to be the "else" clause, meaning that we are expected to have an instance of
the class we compose to. Really, we should be blowing up in that case, as we
can give a much better error message than what they user will likely get (e.g.
`NameError: No method first for String` or something). Still, Ruby is duck
typed, so if the object you're assigning responds to the same methods as the
type you compose to, knock yourself out.

The hash case was added in 36e9be85 to remove a bunch of special cased code from
multiparameter assignment. I wrongly assumed that the only time we'd get a hash
there is in that case. Multiparameter assignment will construct a very specific
hash though, where the keys are integers, and we will have a set of keys
covering `1..part.size` exactly. I'm pretty sure this could actually be passed
around as an array, but that's a different story. Really I should convert this
to something like `class MultiParameterAssignment < Hash; end`, which I might
do soon. However for a change that I'm willing to backport to 4-2-stable, this
is what I want to go with for the time being.

Fixes #25978

`insert`, `update`, `delete`, and `exec_query` have a default value
against `name` and `binds`. But `exec_insert`, `exec_update`, and
`exec_delete` not have. It is an inconvenience and inconsistent.

Because `scope` (`target_scope`) is a `AssociationRelation`.
`AssociationRelation` handles `set_inverse_instance`.

https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/association_relation.rb#L31-L33

See also #26022.

Originally `TransactionSerializationError` was `StatementInvalid` in
Rails 5.0. It should keep backward compatibility.

Because `scope` (`target_scope`) is a `AssociationRelation`.
`AssociationRelation` handles `set_inverse_instance`.

https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/association_relation.rb#L31-L33

Fixes #25892.