The [current documentation of form_for](http://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_for) is incomplete:

> The rightmost argument to form_for is an optional hash of options -
>   :url - The URL the form is to be submitted to. This may be represented in the same way as values passed to url_for or link_to. So for example you may use a named route directly. When the model is represented by a string or symbol, as in the example above, if the :url option is not specified, by default the form will be sent back to the current url (We will describe below an alternative resource-oriented usage of form_for in which the URL does not need to be specified explicitly).
>   :namespace - A namespace for your form to ensure uniqueness of id attributes on form elements. The namespace attribute will be prefixed with underscore on the generated HTML id.
>   :html - Optional HTML attributes for the form tag.

This commit completes the documentation by specifying that:

* `:authenticity_token` is also a valid option (as [documented here](https://github.com/rails/rails/blob/b0f44c9ff0be84ebc42760029adeeb9dd954655f/actionview/lib/action_view/helpers/form_helper.rb#L396))
* `:method` is also a valid option (as [tested here](https://github.com/rails/rails/blob/b0f44c9ff0be84ebc42760029adeeb9dd954655f/actionview/test/template/form_helper_test.rb#L1819))
* `:remote` is also a valid option (as [tested here](https://github.com/rails/rails/blob/b0f44c9ff0be84ebc42760029adeeb9dd954655f/actionview/test/template/form_helper_test.rb#L1850))

[ci skip]

Now ActionView accepts <%= foo(){ %> and <%= foo()do %> ⛳

This reverts commit f93df528, reversing
changes made to a455e3f4.

Conflicts:
	actionpack/lib/action_controller/test_case.rb
	actionview/lib/action_view/test_case.rb

* use public_send instead of send to avoid calling private
  methods in form helpers

This patch uniformizes warning messages. I used the most common style
already present in the code base:

* Capitalize the first word.

* End the message with a full stop.

* "Rails 5" instead of "Rails 5.0".

* Backticks for method names and inline code.

Also, converted a few long strings into the new heredoc convention.

The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.

Heredocs have better readability, and with `squish` we can still
produce a single line.

This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.

The character "*" is unnecessary in option candidates.
This incorrect markup was injected in e8c9aeca .

- Clarify that arguments are expected in array format.
- Extension of https://github.com/rails/rails/pull/17390.
- https://github.com/rails/rails/pull/17390 was targeted against
  4-1-stable branch. This commit updates master.
- [ci skip]

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]

HTML doesn't care what order the elements are rendered in, so why should we?

Updates tests to use proper `assert_dom_equal` instead of `assert_equal` /cc @jeremy

This is to match the changes in Rails Dom Testing rails/rails-dom-testing#20.

This reverts commit 585e7569.

This reverts commit 07635a74, reversing
changes made to 1b5f61a0.

Reason: it's not ready 💣, see https://github.com/rails/rails/pull/16888#issuecomment-56400816

[ci skip]

89ff1f82 and 1de258e6 removed from the HTML generated by the form helpers
the <div> that was wrapping the field elements inside the <form>.

This commit updates the documentation of the methods to reflect the
two commits above.

This is much less common than string literal appends, so add a special
case method for it.  Maybe fixes bug reported by @jeremy on 97ef6361

ERB compiler guarantees safe_append= will be called with a string, so
nil checks don't make sense.  Anything else calling this method should
check for nil themselves before calling

This reverts commit 21ec7fef.

Per #16911, there's actually a good reason for a "blank" value to have a
useful `to_s` here. So let's also add some tests to prove that.

Memoizing will not make possible to assert the output of the view if it
is changed after the first assert_select call

Related with plataformatec/simple_form#1130 and rails/rails-dom-testing#15

not required include ActionView::Helpers::TagHelper in test as well