Make HEAD work / convert to GET once more

This caused a bug with the new associations implementation, because now
association conditions are represented as Arel nodes internally right up
to when the whole thing gets turned to SQL.

In Rails 3.2, association conditions get turned to raw SQL early on,
which prevents Relation#merge from interfering.

The current implementation was buggy when a default_scope existed on the
target model, since we would basically end up doing:

  default_scope.merge(association_scope)

If default_scope contained a where(foo: 'a') and association_scope
contained a where(foo: 'b').where(foo: 'c') then the merger would see
that the same column is representated on both sides of the merge and
collapse the wheres to all but the last: where(foo: 'c')

Now, the RHS of the merge is left alone.

Fixes #8990

because of an ambiguous column name. This happened if the association
model had a default scope that referenced a third table, and the third
table also referenced the original table (with an identical
foreign_key).

Mysql requires that ambiguous columns are deambiguated by using the full
table.column syntax. Postgresql and Sqlite use a different syntax for
updates altogether (and don't tolerate table.name syntax), so the fix
requires always including the full table.column and discarding it later
for Sqlite and Postgresql.

Use `silence` instead of `quietly` to silence the `CheckPending` middleware.

`Kernel.quietly` silences `STDOUT` and `STDERR`, which is useless if
the logger is writing to a file, while `AS::Logger#silence` swaps the
logger level to `ERROR`.

Related to #8820 and #8052.

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

Conflicts:
	actionpack/lib/action_view/helpers/form_options_helper.rb
	guides/code/getting_started/app/controllers/comments_controller.rb

document the behavior of `ActionMailer::Base.delivieries` in tests

thanks @danielpuglisi

`#count` in conjunction with `#uniq` performs distinct count.

closes #6865

Bring back the same API we have with Request::Session.

All ActionPack and Railties tests are passing. Closes #8891.

[Carlos Antonio da Silva + Santiago Pastorino]

Allow passing interpolations to #default_i18n_subject in mailers

Fixes improper database name when creating a new rails app with a '.'

Conflicts:
	railties/CHANGELOG.md

https://github.com/rails/rails/commit/4beb4dececcf10c642c74fbcb8548c833e921a86#commitcomment-2482869

Since the default in Rails 4.0 is to run in 'threadsafe' mode we need
to eager load all of the paths in `autoload_paths` so we alias
`eager_load_paths` to it. This may have unintended consequences if
you have added 'lib' to `autoload_paths` such as loading unneeded
code or code intended only for development and/or test environments.
If this applies to your application you should thoroughly check what
is being eager loaded.

    # config/locales/en.yml
    en:
      user_mailer:
        welcome:
          subject: 'Hello, %{username}'

    # app/mailers/user_mailer.rb
    class UserMailer < ActionMailer::Base
      def welcome(user)
        mail(subject: default_i18n_subject(username: user.name))
      end
    end

or the ConnectionPool silently fails to close connections inside the Thread

This reverts commit 4e05bfb8.

Reason: BlankTopic#blank? should not be removed to check that dynamic finder with a bang can find a model that responds to `blank?`

this would give us some more clues in case a test silently dies inside Thread