Plus a couple of related ActionPack patches.

When the check is failed, print the actual response body if it's not too large.
This could improve productivity when writing new tests.

Before:

```
ThemeEditorIntegrationTest#test_whatever
    Expected response to be a <200: ok>, but was a <422: Unprocessable Entity>.
Expected: 200
  Actual: 422
```

After:

```
ThemeEditorIntegrationTest#test_whatever
    Expected response to be a <200: ok>, but was a <422: Unprocessable Entity>.
Expected: 200
  Actual: 422
Response body: {"errors":["Invalid settings object for section '1'"]}
```

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

Also, refactor logic to convert between symbol and response code,
via the AssertionResponse class

Follow-up to PR #19977, which helpfully added the redirection path to the error message of assert_response if response is a redirection, but which removed the response code, obscuring the type of redirect.

This PR:

- brings back the response code in the error message,

- updates the tests so the new messages can be tested,

- and adds test cases for the change.

- `assert_predicate` appends its own error message at the end of message
  generated by `assert_response` and because of that the error message
  displays the whole `response` object.
- For eg.

  Expected response to be a <success>, but was a redirect to <http://test.host/posts>.
  Expected #<ActionDispatch::TestResponse:0x007fb1cc1cf6f8....(lambda)>}>> to be successful?.

- Complete message can be found here -
  https://gist.github.com/prathamesh-sonpatki/055afb74b66108e71ded#file-gistfile1-txt-L19.

- After this change the message from `assert_predicate` won't be
  displayed and only message generated by `assert_response` will be shown
  as follows:

  Expected response to be a <success>, but was a redirect to <http://test.host/posts>

- If the assert_response is checking for any non-redirect response like
  :success and actual response is :redirect then, the error message displayed
  was -

     Expected response to be a <success>, but was <302>

- This commit adds the redirect path to the error message of
  assert_response if the response is :redirect.
  So above message is changed to -

     Expected response to be a <success>, but was a redirect to <http://test.host/posts/lol>

Following commit https://github.com/rails/docrails/commit/495722a95687e25114ae75608dd3107ac5d6611b

We shouldn't depend on specific methods imlemented in the TestResponse
subclass because the response could actually be a real response object.

In the future, we should either push the aliased predicate methods in
TestResponse up to the real response object, or remove them

`assert_redirected_to` would fail if there is no controller set on
a `ActionDispatch::IntegrationTest`, as _compute_redirect_to_location
would be called on the controller to build the url.

This regression was introduced after 1dacfbab.

[fixes #14691]

This commit makes it really easy to debug errors due to typos like
"assert_response :succezz".

In some instances, `assert_redirected_to` assertion was returning an
incorrect and misleading failure message when the assertion failed.
This was due to a disconnect in how the assertion computes the redirect
string for the failure message and how `redirect_to` computes the
string that is actually used for redirection.

I made the `_compute_redirect_to_loaction` method used by `redirect_to`
public and call that from the method `assert_redirect_to` uses to
calculate the URL.

The reveals a new test failure due to the regex used by
`_compute_redirect_to_location` allow `_` in the URL scheme.

  # File lib/rack/response.rb, line 114
114:       def successful?;    @status >= 200 && @status < 300;       end

add tests for stripping \r\n chars since that's already happening

refactored 'assert_redirected_to': local call to validate_request! will be called in assert_response already. changed names of local variables in order to recognize the semantics a bit easier.

refactored 'assert_redirected_to': local call to validate_request! will be called in assert_response already. changed names of local variables in order to recognize the semantics a bit easier.

Also, no need to include dependencies in AS::Concerns inside included blocks.

We cant use assert_block because its buggy in MiniTest and wont actually show you the failure message you provide -- instead you just always get a "Expected block to return true"

After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.

It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.