This is a variant implementation of the changes proposed in #19914.
Unlike that PR, the change in behavior is isolated in its own class.
This is to prevent wonky behavior if a Proc is assigned outside of the
default, and it is a natural place to place the behavior required by #19921
as well.

Close #19914.

[Sean Griffin & Kir Shatrov]

* Fix a few typos
* Wrap some lines around 80 chars
* Rephrase some statements

We do this in the adapter classes specifically, so the types aren't
registered if we don't use that adapter. Constants under the PostgreSQL
namespace for example are never loaded if we're using mysql.

The same is not true of `define_attribute`, which is meant to be the low
level no-magic API that sits underneath. The differences between the two
APIs are:

- `attribute`
  - Lazy (the attribute will be defined after the schema has loaded)
  - Allows either a type object or a symbol
- `define_attribute`
  - Runs immediately (might get trampled by schema loading)
  - Requires a type object

This was the last blocker in terms of public interface requirements
originally discussed for this feature back in May. All the
implementation blockers have been cleared, so this feature is probably
ready for release (pending one more look-over by me).

`attributes_to_define_after_schema_loads` better describes the
difference between `attribute` and `define_attribute`, and doesn't
conflate terms since we no longer differentiate between "user provided"
and "schema provided" types.

It's finally finished!!!!!!! The reason the Attributes API was kept
private in 4.2 was due to some publicly visible implementation details.
It was previously implemented by overloading `columns` and
`columns_hash`, to make them return column objects which were modified
with the attribute information.

This meant that those methods LIED! We didn't change the database
schema. We changed the attribute information on the class. That is
wrong! It should be the other way around, where schema loading just
calls the attributes API for you. And now it does!

Yes, this means that there is nothing that happens in automatic schema
loading that you couldn't manually do yourself. (There's still some
funky cases where we hit the connection adapter that I need to handle,
before we can turn off automatic schema detection entirely.)

There were a few weird test failures caused by this that had to be
fixed. The main source came from the fact that the attribute methods are
now defined in terms of `attribute_names`, which has a clause like
`return [] unless table_exists?`. I don't *think* this is an issue,
since the only place this caused failures were in a fake adapter which
didn't override `table_exists?`.

Additionally, there were a few cases where tests were failing because a
migration was run, but the model was not reloaded. I'm not sure why
these started failing from this change, I might need to clear an
additional cache in `reload_schema_from_cache`. Again, since this is not
normal usage, and it's expected that `reset_column_information` will be
called after the table is modified, I don't think it's a problem.

Still, test failures that were unrelated to the change are worrying, and
I need to dig into them further.

Finally, I spent a lot of time debugging issues with the mutex used in
`define_attribute_methods`. I think we can just remove that method
entirely, and define the attribute methods *manually* in the call to
`define_attribute`, which would simplify the code *tremendously*.

Ok. now to make this damn thing public, and work on moving it up to
Active Model.

This sets a precident for how we handle `attribute` calls, which aren't
backed by a database column. We should not take this as a conscious
decision on how to handle them, and this can change when we make
`attribute` public if we have better ideas in the future.

As the composed attributes API gets fleshed out, I expect the
`persistable_attributes` method to change to
`@attributes.select(&:persistable).keys`, or some more performant
variant there-of. This can probably go away completely once we fully
move dirty checking into the attribute objects once it gets moved up to
Active Model.

Fixes #18407

Nothing is directly using the columns for the default values anymore.
This step helps us get closer not not mutating the columns hash.

`AttributeSet#dup` has all the behavior we need.

Adding `# :nodoc:` to the parent `class` / `module` is not going
to ignore nested classes or modules.

There is a modifier `# :nodoc: all` but sadly the containing class
or module will continue to be in the docs.

/cc @sgrif

Mostly delegation to start, but we can start moving a lot of behavior in
bulk to this object.

For consistency with https://github.com/rails/rails/pull/15557

The contract of `_field_changed?` assumes that the old value is always
type cast. That is not the case for the value in `Column#default` as
things are today. It appears there are other public methods that
assume that `Column#default` is type cast, as well. The reason for this
change originally was because the value gets put into `@raw_attributes`
in initialize. This reverts to the old behavior on `Column`, and updates
`initialize` to make sure that the values are in the right format.

Many of the methods defined in `AttributeMethods::Serialization` can be
refactored onto this type as well, but this is a reasonable small step.
Removes the `Type` class, and the need for `decorate_columns` to handle
serialized types.

- Create a consistent API across adapters for building new columns
- Use it for custom properties so we don't get `UndefinedMethodError`s
  in stuff I'm implementing elsewhere.

Working towards re-implementing serialized attributes to use the
properties API exposed the need for this, as serializing a column
shouldn't change the order of the columns.

`ActiveRecord::ConnectionAdapters::Type::Value` =>
`ActiveRecord::Type::Value`

Making this part of the public API was premature, let's make it private
again while I continue to work on the surrounding code.

With ActiveRecord::Properties, we now have a reasonable path for users
to continue to keep this behavior if they want it. This is an edge case
that has added a lot of complexity to the code base.

As a result of all of the refactoring that's been done, it's now
possible for us to define a public API to allow users to specify
behavior. This is an initial implementation so that I can work off of it
in smaller pieces for additional features/refactorings.

The current behavior will continue to stay the same, though I'd like to
refactor towards the automatic schema detection being built off of this
API, and add the ability to opt out of automatic schema detection.

Use cases:

- We can deprecate a lot of the edge cases around types, now that there
  is an alternate path for users who wish to maintain the same behavior.
- I intend to refactor serialized columns to be built on top of this
  API.
- Gem and library maintainers are able to interact with `ActiveRecord`
  at a slightly lower level in a more stable way.
- Interesting ability to reverse the work flow of adding to the schema.
  Model can become the single source of truth for the structure. We can
  compare that to what the database says the schema is, diff them, and
  generate a migration.