…ponse format autodetection (yceruto)

This PR was merged into the 4.4 branch.

Discussion
----------

[HttpFoundation][HttpKernel] Improving the request/response format autodetection

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

Mainly for API-based apps, currently the response header `Content-Type` (if no provided) is guessed based on the request format (`_format` attribute), falling back to `html` by default.

Especially for the new error renderer system, where any kind of error can occur and it becomes an http response, this PR improves this guesser mechanism by taking into account also the `Content-type` of the request.

Example:
```bash
$ curl -X POST -H 'Content-Type: application/json' -i 'https://127.0.0.1:8000/login'
```
**before:**
```bash
HTTP/2 500
cache-control: no-cache, private
content-type: text/html; charset=UTF-8 # <- inaccurate
...

{"title":"Internal Server Error","status":500,"detail":"Invalid credentials!"}
```
Most of the 3rd-party bundles that I know (`api-platform/core`, `FOSRestBundle`) need a dedicated listener to achieve it right.

**after:**
```bash
HTTP/2 500
cache-control: no-cache, private
content-type: application/json
...

{"title":"Internal Server Error","status":500,"detail":"Invalid credentials!"}
```
Of course, this applies to all kind of responses, as long as the `Content-Type` is not explicitly provided. So, as a last chance, the `Accept` heading of the request is also taken into account to detect the preferred format:
```bash
$ curl -H 'Accept: application/json' -i 'https://127.0.0.1:8000/userinfo'
HTTP/2 404
cache-control: no-cache, private
content-type: application/json
...

{"title":"Not Found","status":404,"detail":"No route found for \"GET \/userinfo\""}
```
They could be other places in the code where this new method could also be useful, please advise :)

WDYT?

Commits
-------

1952928 Improving the request/response format autodetection

…tPreferredFormat() (dunglas)

This PR was squashed before being merged into the 4.4 branch (closes #32348).

Discussion
----------

[HttpFoundation] Accept must take the lead for Request::getPreferredFormat()

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | n/a
| License       | MIT
| Doc PR        | n/a

Follow up PR to #32344: if both `Accept` and `Content-Type` are defined, `Accept` must take the lead because it explicitly tells what format the client expect as a response.

Before:

```
$ curl -H 'Accept: application/json' -H 'Content-Type: text/xml' -i 'https://127.0.0.1:8000/userinfo'

[snip]
content-type: text/xml
```

After:

```
$ curl -H 'Accept: application/json' -H 'Content-Type: text/xml' -i 'https://127.0.0.1:8000/userinfo'

[snip]
content-type: application/json
```

Actually, I'm not sure that inferring the content type of the response using the `Content-Type` provided for the request body is a good idea. The HTTP RFC explicitly states that `Accept` must be used to hint a preferred response format (`Content-Type` on the request indicates the type of associated its the body). I would be in favor of being more conservative: use `Accept` if provided (a best practice anyway), and fallback to the default value (HTML by default) otherwise. WDYT?

Commits
-------

60d997d [HttpFoundation] Accept must take the lead for Request::getPreferredFormat()