Added changelog entry for table name prefix fix [ci skip]

Closes #6290

Always merge I18n format values, namespaced or not, over the default
ones, to ensure I18n format defaults will have precedence over our
namespaced values.

Precedence should happen like this:

    default :format
    default :namespace :format
    i18n    :format
    i18n    :namespace :format

Because we cannot allow our namespaced default to override a I18n
:format config - ie precision in I18n :format should always have higher
precedence than our default precision for a particular :namespace.

Also simplify default format options logic.

Action Pack already comes with a default locale fine for :en, that is
always loaded. We can just fallback to this locale for defaults, if
values for the current locale cannot be found.

Closes #4420, #2802, #2890.

Removed in 0228a73b, pull request #7310.

Check for Blank Record in form_for

Move AD default_headers configurations to railtie

if nil or an empty array is passed into form_for you get a horrible error message, this one is much more indicative of what the programmer needs to know to fix the problem.

Add documentation for config.action_dispatch.default_headers to
Rails Configuring guide.

Return the conditions from the keep_if call, and ignore the value
argument since it's not being used.

ActionDispatch railtie is a better place for
config.action_dispatch.default_headers settings, users can continue
overriding those settings in their configuration files if needed.

Method compilation provides better performance and I think the code
comes out cleaner as well.

A knock on effect is that methods that get redefined produce warnings. I
think this is a good thing. I had to deal with a bunch of warnings
coming from our tests, though.

When you mount your application at a path, for example /myapp, server
should set SCRIPT_NAME to /myapp. With such information, rails
application knows that it's mounted at /myapp path and it should generate
routes relative to that path.

Before this patch, rails handled SCRIPT_NAME correctly only for regular
apps, but it failed to do it for mounted engines. The solution was to
hardcode default_url_options[:script_name], which is not the best answer
- it will work only when application is mounted at a fixed path.

This patch fixes the situation by respecting original value of
SCRIPT_NAME when generating application's routes from engine and the
other way round - when you generate engine's routes from application.

This is done by using one of 2 pieces of information in env - current
SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because
we have 2 cases to handle:

- generating engine's route from application: in this situation
  SCRIPT_NAME is basically SCRIPT_NAME set by the server and it
  indicates the place where application is mounted, so we can just pass
  it as :original_script_name in url_options. :original_script_name is
  used because if we use :script_name, router will ignore generating
  prefix for engine

- generating application's route from engine: in this situation we
  already lost information about the SCRIPT_NAME that server used. For
  example if application is mounted at /myapp and engine is mounted at
  /blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that
  we need to keep reference to /myapp SCRIPT_NAME by binding it to the
  current router. Later on we can extract it and use when generating url

Please note that starting from now you *should not* use
default_url_options[:script_name] explicitly if your server already
passes correct SCRIPT_NAME to rack env.

(closes #6933)

RouteSet: refactor internals

Well, not all of them, but some of them.

I don't think there's much reason for these methods to be private.

We don't need the complexity of to_sentence, and it shouldn't be a bang
method.

It's not really a good idea to have this as a global config option. We
should allow people to specify the behaviour per association.

There will now be two new values:

* :dependent => :restrict_with_exception implements the current
  behaviour of :restrict. :restrict itself is deprecated in favour of
  :restrict_with_exception.
* :dependent => :restrict_with_error implements the new behaviour - it
  adds an error to the owner if there are dependent records present

See #4727 for the original discussion of this.

Fix #7191. Remove unnecessary transaction when assigning has_one associations.

No need to build valid_conditions array.
We can get all the data in place.

Fix mistake in assertion about content of permanent cookie

Add html_escape note to CHANGELOG

Thanks to Marek Labos & Nethemba

CVE-2012-3465

Introduce default_headers. closes #6311 #6515