Rewrites a CHANGELOG entry.

The entry is basically copy & paste of the commit message, but the CHANGELOG
has a different purpose than Git history, it just communicates what is new:

* No need to explain why did the bug happen (unless it is truly relevant).

* No need to explain how was the bug fixed.

* Whether the user gives new names to columns does not really matter, use of
  select to cherry-pick a column for example also presented that behaviour.
  Non-selected attributes are the key, either because they were not included
  in the selected list, or because they were but with a different alias.

* In the case of an attribute alias, what you really want to depict is that
  respond_to? returns false for the original attribute name.

activerecord/CHANGELOG.md

@@ -1,23 +1,13 @@
 ## Rails 4.0.0 (unreleased) ##
 
-*   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.
+*   If a model was instantiated from the database using `select`, `respond_to?`
+    returns false for non-selected attributes. For example:
 
-        post = Post.select("'title' as post_title").first
+        post = Post.select(:title).first
+        post.respond_to?(:body) # => false
 
-    In the above case when `post.body` is invoked then an exception is
-    raised since `body` attribute is not selected. However `respond_to?`
-    did not behave correctly.
-
-        post.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.
+        post = Post.select('title as post_title').first
+        post.respond_to?(:title) # => false
 
     Fixes #4208.