…ar, also configures the default logger (nicolas-grekas)

This PR was merged into the 3.4 branch.

Discussion
----------

[Console][HttpKernel] Handle new SHELL_VERBOSITY env var, also configures the default logger

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

On the CLI, the behavior of the new default logger is not nice: it's verbosity is controlled by `kernel.debug`, where I would expect to be able to control it by mean of verbosity.
To achieve this, I propose to handle a new `SHELL_VERBOSITY` env var, and use it to control both commands' verbosity, and the logger's log level.

Commits
-------

87bd741 [Console][HttpKernel] Handle new SHELL_VERBOSITY, also configures the default logger

symfony/symfony#53632 made it so that the --silent option is now provided & managed by the symfony core itself which would have been all well and good, except for the fact that since symfony/symfony#24425 symfony has been persisting the selected verbosity layer in the environment. This means that if you have a test that calls a command with the --silent flag set, and then it's followed by a test that relies on the --silent flag not being set, that second test (and any future test that expects the --silent flag not to be set) will also fail.

This leads to all sorts of headaches around tests failing depending on the order they are run in, whether or not you're running a single test case or multiple, or even whether the environment you're running the tests in actually supports putenv().

Massive credit to @jaxwilko for finding the issue and coming up with the solution.

symfony/symfony#53632 made it so that the --silent option is now provided & managed by the symfony core itself which would have been all well and good, except for the fact that since symfony/symfony#24425 symfony has been persisting the selected verbosity layer in the environment. This means that if you have a test that calls a command with the --silent flag set, and then it's followed by a test that relies on the --silent flag not being set, that second test (and any future test that expects the --silent flag not to be set) will also fail.

This leads to all sorts of headaches around tests failing depending on the order they are run in, whether or not you're running a single test case or multiple, or even whether the environment you're running the tests in actually supports putenv().

Massive credit to @jaxwilko for finding the issue and coming up with the solution.