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

Follow up to #15438 and #15502.

/cc @sgrif

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.

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

It appears to have been used at some point in the past, but is no longer
used in any meaningful way. Whether a column is considered primary is
a property of the model, not the schema/column. This also removes the
need for yet another layer of caching of the model's schema, and we can
leave that to the schema cache.

2d73f5ae forces AR to enter the `define_attribute_methods` method whenever it
instantiate a record from the `init_with` entry point. This is a potential
performance hotspot, because `init_with` is called from all `find*` family
methods, and `define_attribute_methods` is slow because it tries to acquire
a lock on the mutex everytime it is entered.

By using [DCL](http://en.wikipedia.org/wiki/Double-checked_locking), we can
avoid grabbing the lock most of the time when the attribute methods are already
defined (the common case). This is made possible by the fact that reading an
instance variable is an atomic operation in Ruby.

Credit goes to Aaron Patterson for pointing me to DCL and filling me in on the
atomicity guarantees in Ruby.

[*Godfrey Chan*, *Aaron Patterson*]

Improve documentation

Add tests to make sure scopes cannot be create with names such as:
private, protected, public.
Make sure enum values don't collide with those methods too.

PR #14052 Added a regression where it was only looking for methods in one
level up, So when the method was defined in a 2+ levels up the
inheritance chain, the method was not found as defined.

conflicting private method defined on its ancestors.

The problem is that `method_defined_within?(name, klass, superklass)`
only works correclty when `klass` and `superklass` are both `Class`es.

If both `klass` and `superklass` are both `Class`es, they share the
same inheritance chain, so if a method is defined on `klass` but not
`superklass`, this method must be introduced at some point between
`klass` and `superklass`.

This does not work when `superklass` is a `Module`. A `Module`'s
inheritance chain contains just itself. So if a method is defined on
`klass` but not on `superklass`, the method could still be defined
somewhere upstream, e.g. in `Object`.

This fix works by avoiding calling `method_defined_within?` with a
module while still fufilling the requirement (checking that the
method is defined withing `superclass` but not is not a generated
attribute method).

4d8ee288 is likely an attempted partial fix for this problem. This
unrolls that fix and properly check the `superclass` as intended.

Fixes #11569.

Fixing issue with activerecord serialization not being able to dump a record after loading it from YAML - fixes #13861

Similar to dangerous attribute methods, a scope name conflict is
dangerous if it conflicts with an existing class method defined within
`ActiveRecord::Base` but not its ancestors.

See also #13389.

*Godfrey Chan*, *Philippe Creux*

This was happening when a `super` call in an overwritten attribute method
was triggering a method_missing fallback, because attribute methods
haven't been generated yet.

  class Topic < ActiveRecord::Base
    def title
      # `super` would re-invoke this method if define_attribute_methods
      # hasn't been called yet resulting in double '!' appending
      super + '!'
    end
  end

TS::Cache#compute_if_absent guarantees that only a single thread will get to execute the provided block for a given key.

for attributes that are columns.