Allow specifying TLS hostname independently from destination IP for DNS-over-TLS (DoT) upstreams

### Prerequisites

- [x] I have checked the [Wiki](https://github.com/AdguardTeam/AdGuardHome/wiki) and [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions) and found no answer

- [x] I have searched other issues and found no duplicates

- [x] I want to request a feature or enhancement and not ask a question

### The problem

Currently, when configuring DNS-over-TLS (DoT) upstreams in AdGuard Home, there is no way to explicitly specify the hostname used for SNI and certificate validation independently from the IP address used for the network connection.

As a result, it is not possible to connect directly to a specific IP address while explicitly validating the identity of the intended upstream resolver.

Example use cases:

Connect to:

```text
1.1.1.1
```

Validate as:

```text
one.one.one.one
```

Or:

Connect to:

```text
9.9.9.10
```

Validate as:

```text
dns10.quad9.net
```

The hostname used for certificate validation is an important security control because it verifies not only that the connection is encrypted, but also that the client is communicating with the intended DNS provider.

For example, the following command intentionally connects to Cloudflare's IP address while validating it as Quad9:

```bash
kdig +tls-host=dns10.quad9.net +tls @1.1.1.1 google.com
```

This correctly fails:

```text
;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server 1.1.1.1@853(TCP)
```

Using the correct hostname succeeds:

```bash
kdig +tls-host=one.one.one.one +tls @1.1.1.1 google.com
```

Result:

```text
;; TLS session (TLS1.3) ...
;; status: NOERROR
```

This capability helps detect and prevent:

* ISP redirection
* Transparent DNS proxies
* Routing mistakes
* Misconfigured upstream IP addresses
* Connections to an unintended DNS provider
* TLS endpoints presenting a certificate for a different resolver

### Proposed solution

Provide a way to configure the destination IP address independently from the hostname used for:

* SNI
* Certificate validation
* Upstream identity verification

The exact configuration syntax is not important and can be determined by the maintainers.

One possible configuration could be:

```yaml
upstream_dns:
- tls://one.one.one.one@1.1.1.1
- tls://dns10.quad9.net@9.9.9.10
```

Which would mean:

* Connect to `1.1.1.1`
* Use `one.one.one.one` for SNI
* Validate the certificate against `one.one.one.one`

And:

* Connect to `9.9.9.10`
* Use `dns10.quad9.net` for SNI
* Validate the certificate against `dns10.quad9.net`

Expected behavior:

* Establish the connection to the configured IP address.
* Send the configured hostname as SNI.
* Validate the certificate against the configured hostname.
* Reject the connection if the certificate does not match the configured hostname.

Benefits:

* Ability to connect directly to IPv4 or IPv6 addresses while maintaining proper certificate validation.
* Reduced dependency on bootstrap DNS in some deployments.
* Easier troubleshooting of encrypted DNS configurations.
* More explicit and auditable upstream identity verification.

Many TLS-enabled clients already allow the connection endpoint and the validated TLS identity to be configured independently. Supporting the same capability in AdGuard Home would improve both security and operational flexibility while remaining fully backward compatible with existing configurations.

### Alternatives considered and additional information

_No response_