Object#respond_to? returns singletons and thus we inherit that contract.
The implementation of the predicate is good, but the test is only
checking boolean semantics, which in this case is not enough.

fixes #4208

If a query selects only a few columns and gives custom names to
those columns then respond_to? was returning true for the non
selected columns. However calling those non selected columns
raises exception.

    post = Post.select("'title' as post_title").first

In the above case when `post.body` is invoked then an exception is
raised since `body` attribute is not selected. Howevere `respond_to?`
did not behave correctly.

    pos.respond_to?(:body) #=> true

Reason was that Active Record calls `super` to pass the call to
Active Model and all the columns are defined on Active Model.

Fix is to actually check if the data returned from the db contains
the data for column in question.

We should not need any `serialized_attributes` checks outside `ActiveRecord::AttributeMethods::Serialization` module.

This fixes the following behaviour:

    class Person < ActiveRecord::Base
      belongs_to :company
    end

    # Before:
    person = Person.select('id').first
    person[:name]       # => nil
    person.name         # => ActiveModel::MissingAttributeError: missing_attribute: name
    person[:company_id] # => nil
    person.company      # => nil

    # After:
    person = Person.select('id').first
    person[:name]       # => ActiveModel::MissingAttributeError: missing_attribute: name
    person.name         # => ActiveModel::MissingAttributeError: missing_attribute: name
    person[:company_id] # => ActiveModel::MissingAttributeError: missing_attribute: company_id
    person.company      # => ActiveModel::MissingAttributeError: missing_attribute: company_id

Fixes #5433.

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.

When inserting new records, only the fields which have been changed
from the defaults will actually be included in the INSERT statement.
The other fields will be populated by the database.

This is more efficient, and also means that it will be safe to
remove database columns without getting subsequent errors in running
app processes (so long as the code in those processes doesn't
contain any references to the removed column).

ActiveRecord#attributes optimization: minimize objects created

From 2c667f69.

Thanks @pwnall for the heads-up.

This reverts commit 21eadc1b.

This is the 'top level' connection, inherited by any models that include
ActiveRecord::Model or inherit from ActiveRecord::Base.

This is good because it reduces duplication.

Instead of generating association methods directly in the model
class, they are generated in an anonymous module which
is then included in the model class. There is one such module
for each association. The only subtlety is that the
generated_attributes_methods module (from ActiveModel) must
be forced to be included before association methods are created
so that attribute methods will not shadow association methods.

There is no meaningful performance penalty in defining attribute
methods, since it only happens once.

There is also no reason *not* to define them, since they get thrown in
an included module, so they will not 'overwrite' anything. In fact, this
is desirable, since it allows us to call super.