While we don't want to change the form input when validations fail,
blindly using `_before_type_cast` will cause the input to display the
wrong data for any type which does additional work on database values.

In the case of serialized columns, we would expect the unserialized
value as input, not the serialized value. The original issue which made
this distinction, #14163, introduced a bug. If you passed serialized
input to the method, it would double serialize when it was sent to the
database. You would see the wrong input upon reloading, or get an error
if you had a specific type on the serialized column.

To put it another way, `update_column` is a special case of
`update_all`, which would take `['a']` and not `['a'].to_yaml`, but you
would not pass data from `params` to it.

Fixes #18037

This was a small self contained piece of the refactoring that I am
working on, which required these objects to be comparable.

Making this change revealed several subtle bugs related to models with
no primary key, and anonymous classes. These have been fixed as well,
with regression tests added.

This allows using polymorphism for the uninitialized attributes raising
an exception behavior.

This will make it less painful to add additional properties, which
should persist across writes, such as `name`.

Conflicts:
	activerecord/lib/active_record/attribute_set.rb

Moved `Builder` to its own file, as it started looking very weird once I
added private methods to the `AttributeSet` class and the `Builder`
class started to grow.

Would like to refactor `fetch_value` to change to

```ruby
self[name].value(&block)
```

But that requires the attributes to know about their name, which they
currently do not.

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

There's a lot more that can be moved to these, but this felt like a good
place to introduce the object. Plans are:

- Remove all knowledge of type casting from the columns, beyond a
  reference to the cast_type
- Move type_cast_for_database to these objects
- Potentially make them mutable, introduce a state machine, and have
  dirty checking handled here as well
- Move `attribute`, `decorate_attribute`, and anything else that
  modifies types to mess with this object, not the columns hash
- Introduce a collection object to manage these, reduce allocations, and
  not require serializing the types