Nearly completely implemented in terms of custom properties.
`_before_type_cast` now stores the raw serialized string consistently,
which removes the need to keep track of "state". The following is now
consistently true:

- `model.serialized == model.reload.serialized`
- A model can be dumped and loaded infinitely without changing
- A model can be saved and reloaded infinitely without changing

During `init_with`, the attributes given to the coder will be placed
into `@raw_attributes`. As such, we should read from `@raw_attributes`
when encoding, rather than `@attributes`, which has been type cast.

The first case was not testing what the issue mentioned actually was (A
subclass of a class with serialized attributes does not serialize when
they come from the database).

The second case was a bad coder. It would fail if the model was `dup`ed,
or if the the model was loaded from the database and then saved again.

The third case wasn't testing anything that wasn't covered by the second
(and was also a bad coder for the same reasons as the second).

`@attributes` was actually used for `_before_type_cast` and friends,
while `@attributes_cache` is the type cast version (and caching is the
wrong word there, but I'm working on removing the conditionals around
that). I opted for `@raw_attributes`, because `_before_type_cast` is
also semantically misleading. The values in said hash are in the state
given by the form builder or database, so raw seemed to be a good word.

This removes the case statement in `SchemaDumper` and gives every `Type`
the possibility to control the SchemaDumper default value output.

/cc @sgrif

This is an intermediate solution. It is related to the refactoring @sgrif
is making and will change in the future.

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.

MySQL and PostgreSQL provide a column type override in order to properly
type cast computed columns included in a result set. This should never
override the known types of full fledged columns. In addition to messing
up computed properties, this would have led to inconsistent behavior
between a record created with `new`, and a record created with `last` on
the mysql adapter in the following cases:

- `tinyint(1)` with `emulate_booleans` set to `false`
- `text`, `string`, `binary`, and `decimal` columns

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

It appears this property was added, but never actually used. It would be
broken if it were, as it only type casts one way.

The solution presented in this patch is not efficient. We should replace it
in the near future. The following needs to be worked out:
  * Is `@attributes` storing the Ruby or SQL representation?
  * `cacheable_column?` is broken but `hstore` and `json` rely on that behavior

Refs #15369.

/cc @sgrif @rafaelfranca

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

Missed a case that only occured for mysql/mysql2

This PR fixes #8930 and some stuff from #8985

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.

After ad7b5efb, which changed how
has_an_belongs_to_many used to work, we start raising an error when
redefining the same has_an_belongs_to_many association. This commits fix
that regression.

[Fixes #14983]

All preload tests are in the eager_test file