* Fix example queries
* Remove doc entries of where.like/not_like.
* Remove :chain from where.not related docs. To me that's an implementation
  detail and we don't expect people to use where(:chain).not.

Fix #assert_instance_method to also assert indented methods

use _action callbacks in actionmailer

Use attr_accessor for Rails.{application,cache,logger}

Update AR Changelog with correct example using includes [ci skip]

These queries don't seem to work without the includes clause. [ci skip]

Update guides to use _action callbacks [ci skip]

use :only instead of :except callback option in the controller template

As [Security Guide](http://edgeguides.rubyonrails.org/security.html#whitelists-versus-blacklists)
says, it's better to use `before_filter only: []` instead of `except: []`
so we don't forget to turn the filter off for newly added actions.

Actionize2

Actionize: Use `_action` callbacks in documentation and code

Rename ActiveSupport::BasicObject to ActiveSupport::ProxyObject

AS::BasicObject is used for proxy classes. Let's give it a less concerning
name. Also, it avoids the confusion with Ruby's Basic Object.

The real win with these chain methods is where.not, that takes care of
different scenarios in a graceful way, for instance when the given value
is nil.

    where("author.id != ?", author_to_ignore.id)
    where.not("author.id", author_to_ignore.id)

Both where.like and where.not_like compared to the SQL versions doesn't
seem to give us that much:

    Post.where("title LIKE 'ruby on%'")
    Post.where.like(title: 'ruby on%'")
    Post.where("title NOT LIKE 'ruby on%'")
    Post.where.not_like(title: 'ruby on%'")

Thus Rails is adding where.not, but not where.like/not_like and others.

Document the types of arguments accepted by AR#not

This commit stems from https://github.com/rails/rails/pull/8332#issuecomment-11127957

Since the formats in which conditions can be passed to `not` differ
from the formats in which conditions can be passed to `like` and `not_like`,
then I think it's worth adding rdoc and tests to show this behavior

The force flag suggests the original was probably copied
from some db/schema.rb. Thanks to Josh Susser for spotting
and reporting this.

Shelling out was there for authors convenience, but we are
rather going to have the tag or SHA1 always in RAILS_VERSION
and if the environment variable is blank, then just use
"local" as a reminder that you are just working locally.

The docs server has been updated to set the long SHA1 in
RAILS_VERSION when generating edge guides.

Arel::Nodes::In inherits from Arel::Nodes::Equality, so the case
statement was always using the Equality operator for both scenarios,
resulting in a not equal query instead.

Update #where rdoc to match 6ba0f975 [ci skip]

This commit updates the rdoc of AR#where to match the changes applied
in https://github.com/rails/rails/commit/6ba0f97 that is:

* `where(nil)` has the same effect of `where('')`: a no op
* `where` (no args) has the same effect of `where(:chain)`: to create a WhereChain

This reverts commit c59734f7.

This test does not belong to has many associations test.

Consider this scenario:

    if params[:foo]
      conditions = { foo: true }
    end

    foos = Foo.where(conditions).order(:id)

When params[:foo] is nil, this would call:

    foos = Foo.where(nil).order(:id)

In this scenario, we want Foo.where(conditions) to be the same as calling
Foo.all, otherwise we'd get a "NoMethodError order for WhereChain".

Related to #8332.

Relation.where with no args can be chained with not, like, and not_like

Conflicts:
	activerecord/CHANGELOG.md
	activerecord/lib/active_record/relation/query_methods.rb

When applying default_scope to a class with a where clause, using
update_column(s) could generate a query that would not properly update
the record due to the where clause from the default_scope being applied
to the update query.

    class User < ActiveRecord::Base
      default_scope where(active: true)
    end

    user = User.first
    user.active = false
    user.save!

    user.update_column(:active, true) # => false

In this situation we want to skip the default_scope clause and just
update the record based on the primary key. With this change:

    user.update_column(:active, true) # => true

Fixes #8436.