Earlier
when `data-disable-with` option is added direclty as in options then

```ruby
submit_tag("Save", { "data-disable-with" => "Processing..." })
# => <input type="submit" name="commit" value="Save" data-disable-with="Processing..." data-disable-with="Processing..." />
```

Now
when `data-disable-with` option is added direclty as in options then

```ruby
submit_tag("Save", { "data-disable-with" => "Processing..." })
# => <input type="submit" name="commit" value="Save" data-disable-with="Processing..." />
```

Prevents double submission by making disable_with the default.

Default disable_with option will only be applied if user has not
specified her/his own disable_with option, whether that is in the
`data-disable-with` string form or the
`:data => { :disable_with => "Saving..." }` hash form. disable_with
will default to the value attribute.

A configuration option was added to opt out of this functionality if
the user so desires.
`config.action_view.automatically_disable_submit_tag = false`

content_tag's first argument is will generate a string with an html tag so `:a` will generate: `<a></a>`. When this happens, the symbol is implicitly `to_s`-d so a new string is allocated. We can get around that by using a frozen string instead which

This change buys us 74,236 bytes of memory and 1,855 fewer objects per request.

The 'selected' option is not doing what it should do.
The expected behavior is to pass the value selected by default for the options_from_collection_for_select method

Fixes https://github.com/rails/rails/issues/17701.

Update select_tag to reflect documentation and behave the same as form builder select. If the value of include_blank is not boolean true, use that value as the option label.

This commit fixes the behavior of `file_field_tag` and `password_field_tag`
when invoked with a hash of options.

These two helpers are different from all the other ones in that they modify the
options hash passed as a parameter, whereas all the other helpers duplicate it
before updating it.

The result is that *bad things* can happen if the user re-uses the same hash.
For instance, users who write the following code to display a file field
followed by a text field (both with the same class):

```rhtml
<% options = {class: 'important'} %>
<%= file_field_tag 'Upload', options %>
<%= text_field_tag 'Name', options %>
```

would instead see **two file fields!**

```html
<input class="important" id="Upload" name="Upload" type="file">
<input class="important" id="Name" name="Name" type="file" value="value">
```

This PR replaces `update` with `merge` in the code of the two helpers,
fixing the issue above.

The included test verifies the change, since it passes after this PR, but
fails before with the following error:

```
Expected: <input type="text" name="title" id="title" value="Hello!" class="important" />
Actual: <input type="password" name="title" id="title" value="Hello!" class="important" />
```

All the methods that invoke `text_field_tag` (such as `hidden_field_tag`)
and all the methods that invoke `number_field_tag` (that is `range_field_tag`)
do not need to call `stringify_keys` on their `options` parameter since the
`text_field_tag` method [is already doing it internally](https://github.com/claudiob/rails/blob/4159134524f4c78d008eef9d9a17f73a3172dcc8/actionview/lib/action_view/helpers/form_tag_helper.rb#L182):

```ruby
def text_field_tag(name, value = nil, options = {})
  tag :input, { "type" => "text", "name" => name, "id" => sanitize_to_id(name), "value" => value }.update(options.stringify_keys)
end
```

and `number_field_tag` is [already doing it internally](https://github.com/claudiob/rails/blob/e3207bdbba55f3806441f22b175557579bc0b051/actionview/lib/action_view/helpers/form_tag_helper.rb#L780) as well:

```ruby
def number_field_tag(name, value = nil, options = {})
  options = options.stringify_keys
  ...
end

[Note #1: My code uses `merge` to respect the existing behavior of
duplicating the `options` hash before updating its keys, see https://github.com/rails/rails/pull/17096#issuecomment-57223827]

[Note #2: My code uses symbols instead of strings (e.g.: `:hidden`) to look
forward to future version of Ruby/Raiks (GC symbols); the result of the method,
however, is the same, because the symbols are stringified inside `text_field_tag`]

[Note #3: I had previously created a similar PR #17096 but decided to
split it into multiple PRs given the feedback received in the comments]

This is true of the first param (url_for_options),
not of the second options param which is being
documented here.

[ci skip]

Docs for all the other form tag helpers in this
file already clarify this.

[ci skip]

    see cc255d34

In actionview, eliminate calls to tag that use html_safe parameter values. This is generally unnecessary, since tag handles string quoting, except in one case (utf8_enforcer_tag) where we want to specify the encoding ourselves.

We are dropping HTML 4.01 and XHTML strict compliance since input
tags directly inside a form are valid HTML5, and the absense of
inline styles help in validating for Content Security Policy.

There's no need to rely on Active Support's Hash#reverse_merge for
simple cases with default values, since we can just merge from the
default rather than reverse merge from the options.

This also avoids the creation of one extra hash object by moving to a
Hash#merge! call.