Uniformize TLS configuration

Many Log4j components have a configuration attribute to enable the verification of the TLS server certificate:

- Network appenders (`Socket`, `SMTP`) use the [`verifyHostname`](https://logging.apache.org/log4j/2.x/manual/appenders.html#ssl-configuration) attribute of the `SSL` nested component to provide the same feature. Its default value is `false`.

- The [HTTP Appender](https://logging.apache.org/log4j/2.x/manual/appenders.html#HttpAppender) has a configuration attribute `verifyHostname`. The value defaults to `true`. Note that the HTTP Appender can also have a nested `SSL` component, but the value of `SSL.verifyHostname` is ignored.

- We also have a `log4j2.sslVerifyHostName` configuration property that is used if the `SSL` component is absent.

I understand that in the past only HTTP servers had a X509 certificate issued by a public CA. However nowadays most SMTP servers have also publicly verifiable X509 certificates, so we can switch both defaults to `true`.

Besides that a public X509 certificate was never required by our appenders: they only connect to a single host.

## Proposed changes

- Let us deprecate `HTTP.verifyHostname` in `2.x`. In `3.x` we can still keep it, but set its default value to `SSL.verifyHostname`.
- We can switch the default value of `SSL.verifyHostname` to `true`. This might require some additional work: the SMTP and HTTP appenders only connect to the host, when there is a log event to send. In the case of SMTP this happens only for `ERROR` log events by default, so users might realize that they have a configuration problem much later.
- Currently if the user configures an `SSL` element, all the `log4j2.ssl*` configuration properties are ignored. I think those properties should still be used to provide default values for `SSL`.