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

Adds the ability to save custom types, which type cast to non-primitive
ruby objects.

The `:timestamp` type for columns is unused. All database adapters treat
them as the same database type. All code in `ActiveRecord` which changes
its behavior based on the column's type acts the same in both cases.
However, when the type is passed to code that checks for the `:datetime`
type, but not `:timestamp` (such as XML serialization), the result is
unexpected behavior.

Existing schema definitions will continue to work, and the `timestamp`
type is transparently aliased to `datetime`.

With the addition of String#in_time_zone and Date#in_time_zone
we can simplify the type casting code by checking if the value
has an `in_time_zone` method.

Previously, when `time_zone_aware_attributes` were enabled, after
changing a datetime or timestamp attribute and then changing it back
to the original value, `changed_attributes` still tracked the
attribute as changed. This caused `[attribute]_changed?` and
`changed?` methods to return true incorrectly.

Example:

    in_time_zone 'Paris' do
      order = Order.new
      original_time = Time.local(2012, 10, 10)
      order.shipped_at = original_time
      order.save
      order.changed? # => false

      # changing value
      order.shipped_at = Time.local(2013, 1, 1)
      order.changed? # => true

      # reverting to original value
      order.shipped_at = original_time
      order.changed? # => false, used to return true
    end

This reverts commit e9d2ad39.

Closes #8460

Conflicts:
	activerecord/lib/active_record/attribute_methods/time_zone_conversion.rb
	activerecord/test/cases/dirty_test.rb

Setting a nil datetime attribute to a blank string should not cause the
attribute to be dirty.

Fix #8310

In the end I think the pain of implementing this seamlessly was not
worth the gain provided.

The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.

This reverts commit 83846838.

I think it's going to be too much pain to try to transition the
:active_record load hook from executing against Base to executing
against Model.

For example, after Model is included in Base, and modules included in
Model will no longer get added to the ancestors of Base.

So plugins which wish to be compatible with both Model and Base should
use the :active_record_model load hook which executes *before* Base gets
loaded.

In general, ActiveRecord::Model is an advanced feature at the moment and
probably most people will continue to inherit from ActiveRecord::Base
for the time being.

This reverts commit 86c3dfbd.

Conflicts:
	activerecord/lib/active_record/attribute_methods/read.rb

Reason: whilst this increased performance, it also presents a DoS risk
via memory exhaustion if users were allowing user input to dictate the
arguments of read/write_attribute. I will investigate alternative ways
to cut down on string allocations here.

This is a performance/GC optimisation.

In theory, this could be optimised by the implementation (last time I
checked, this would have no effect on JRuby). But in practise, this make
attribute access faster.

Get rid of ActiveModel::Configuration, make better use of
ActiveSupport::Concern + class_attribute, etc.

copy the columns hash to the active record instances, typecast using columns looked up on the instance

The problem: We need to be able to specify configuration in a way that
can be inherited to models that include ActiveRecord::Model. So it is
no longer sufficient to put 'top level' config on ActiveRecord::Base,
but we do want configuration specified on ActiveRecord::Base and
descendants to continue to work.

So we need something like class_attribute that can be defined on a
module but that is inherited when ActiveRecord::Model is included.

The solution: added ActiveModel::Configuration module which provides a
config_attribute macro. It's a bit specific hence I am not putting this
in Active Support or making it a 'public API' at present.

We also need to time zone convert time zone aware attributes when
accessed via read_attribute, not only when via direct access.

This is good because it reduces duplication.

Define singleton methods on the attributes module instead. This reduces
method pollution on the actual model classes. It also seems to make
something faster, I am unsure why! O_o

After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.

It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.

There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.

Fix before_type_cast for timezone aware attributes by caching converted value on write. Also remove read method reload arg on timezone attributes.

Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

[#3973 state:committed]
Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

class inheritable attributes is used no more! all internal use of class inheritable has been changed to class_attribute. class inheritable attributes has been deprecated.
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Cheaper attribute reads and respond_to?. Add underscore-prefixed method aliased to the attribute name so it can be overridden but still called internally.