There are some minor changes to the point type as I had forgotten that
this will affect the behavior of `t.point` in migrations and the schema
dumper so we need to handle those as well.

I'll say this again so I can convince myself to come up with a better
structure... TYPES SHOULD NOT CARE ABOUT SCHEMA DUMPING AND WE NEED TO
BETTER SEPARATE THESE.

use `message` that specified in argument to error message

This reverts commit 3a1f6fe7.

This commit takes the code in a direction that I am looking to avoid.
The predicate builder should be purely concerned with AST construction
as it matters to methods like `where`. Things like case sensitivity
should continue to be handled elsewhere.

I still think that this is something that should be handled in the pg
gem, but it's not going to end up happening there so we'll do it here
instead. Once we bump to pg 0.19 we can pass the encoding to the
`encode` method instead.

This issue occurs because C has no concept of encoding (or strings,
really). The bytes that we pass here when sending the value to the
database will always be interpreted as whatever encoding the connection
is currently configured to use. That means that roundtripping to the
database will lose no information

However, after assigning we round trip through our type system without
hitting the database. The only way that we can do the "correct" thin
here would be to actually give a reference to the connection to the
array type and have it check the current value of the connection's
encoding -- which I'm strongly opposed to. We could also pass in the
encoding when it's constructed, but since that can change independently
of the type I'm not a huge fan of that either.

This feels like a reasonable middle ground, where if we have an array of
strings we simply use the encoding of the string we're given.

Fixes #26326.

This was almost every case where we are overriding `respond_to?` in a
way that mirrors a parallel implementation of `method_missing`. There is
one remaining case in Active Model that should probably do the same
thing, but had a sufficiently strange implementation that I want to
investigate it separately.

Fixes #26333.

Make public asset use explicit

Use splat `options` hash for `has_and_belongs_to_many`

Add `Type.default_value` and use it everywhere for internal

If a parent association was accessed in an `after_find` or
`after_initialize` callback, it would always end up loading the
association, and then immediately overwriting the association we just
loaded. If this occurred in a way that the parent's `current_scope` was
set to eager load the child, this would result in an infinite loop and
eventually overflow the stack.

For records that are created with `.new`, we have a mechanism to
perform an action before the callbacks are run. I've introduced the same
code path for records created with `instantiate`, and updated all code
which sets inverse instances on newly loaded associations to use this
block instead.

Fixes #26320.

Refactor remove duplication.

[ci skip] Broken links in documentation fix

Don't unnecessarily load a belongs_to when saving.

Update typo & Make explanation more clear

Fix performance regression in `TimeWithZone#to_time`

Allow `send_file` to declare a charset

Removed my patch in favor of @tenderlove's less invasive approach.

[Aaron Patterson & Jon Moss]

Is this usage correct? cc/ @prathamesh-sonpatki