Special config needed for wildcard certs, when using clientid over DoT or DoQ

### Issue Details

* **Version of AdGuard Home server:**
v0.107.7
* **How did you install AdGuard Home:**
GitHub release on Oracle Cloud VPS
* **How did you setup DNS configuration:**
On the AGH instance or clients? AGH is forwarding to Quad9 DoT.
* **If it's a router or IoT, please write device model:**
N/A
* **CPU architecture:**
ARM64
* **Operating system and version:**
Ubuntu 20.04.4 LTS aarch64

### Expected Behavior
The AGH server runs on an Oracle Cloud VPS. Its domain name is `dns.domain.xyz` and it is (was) using a wildcard cert from LetsEncrypt, and later ZeroSSL (via acme.sh). Therefore, encrypted client URLs using a clientid are:

`https://dns.domain.xyz/dns-query/my-mbp`
`tls://my-mbp.dns.domain.xyz`
`quic://my-mbp.dns.domain.xyz`

AGH has clientid set up appropriately, under 'Client settings'. For example 'Client name' is 'my-mbp' and 'Identifier' is also 'my-mbp'.

According to the Wiki and what I read on various tickets here in the Issues, with a regular wildcard cert clients should be able to connect to any or all of those endpoints and experience encrypted DNS. Indeed, the cert for the current beta of AdGuard Personal DNS (adguard-dns.io) shows a 'regular' wildcard cert, with the CN showing `*.adguard-dns.io` and it being valid for the domains of `*.adguard-dns.io` and `adguard-dns.io`.

For me though, generating a cert like that simply won't work with client IDs over TLS, as follows:

### Actual Behavior
As per some other tickets on this matter (which are closed, and don't cover my exact issue at all - hence making a new one), DoH with a clientid works fine using the https endpoint. DNS over TLS does work **if** you just use `dot://dns.domain.xyz`, but doesn't work at all if you use a clientid as well (like `tls://my-mbp.dns.domain.xyz`).

Various resolvers (Unbound, Knot Resolver, Stubby) being pointed to `clientid.dns.domain.xyz` all complain about the certificate not matching the domain. Setting the AGH log to verbose also confirms the issue, and fills up on every attempt to resolve a domain, with:

2022/07/06 21:52:36.726059 1347#38 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).handleTCPConnection(): handling tcp: started handling tls request from 1.2.3.4:53232
2022/07/06 21:52:36.760977 1347#38 [error] handling tcp: reading msg: reading len: remote error: tls: bad certificate

This is despite a valid wildcard cert being in place (tested using both LetsEncrypt and ZeroSSL certs valid for `*.domain.xyz` and `domain.xyz`). I tried to debug this last year and gave up, but this time it was annoying me so I got it fixed.

Initially, I suspected the Oracle Cloud VPS or its installed OS of having some weird config issue or corruption. So I span up a FreeBSD 13 instance on Vultr and clean installed AGH (again from the Github release) there and replicated my config. That had the same issue, so I knew it was actually my cert or AGH itself.

As it turns out, I **can** make clientid over TLS work if, instead of generating a 'standard' wildcard cert I generate using one extra parameter for `-d *.dns.domain.xyz` like this:

acme.sh --issue -d domain.xyz -d '*.domain.xyz' -d '*.dns.domain.xyz' --dns dns_cf --keylength ec-384

Now, the errors stop, the resolvers are all happy (tested on `systemd-resolved`, `unbound`, `kresd` (knot-resolver) and `stubby`) and DNS over TLS with a clientid works perfectly as it should. My question/issue, is that all the (sparse) documentation I've seen on this matter suggests a regular wildcard cert with two domains/common names (domain and *.domain) will work, but it doesn't. Effectively, wildcards only go one subdomain deep, where `dns.domain.xyz` would need two subdomains deep for `clientid.dns.domain.xyz`.

Does anyone know why?

Interestingly, if it's any use in debugging the issue, even on previous regular wildcard cert (which caused straight `SERVFAIL` in all other resolvers), I *could* get `systemd-resolved` to work over TLS, by setting `DNSOverTLS=opportunistic`. I'm assuming that the parameter doesn't just mean 'use TLS if it's there, and use regular DNS if it isn't', but rather also '...and if a cert is there, don't look too closely at the TLS certificate and domains - just use TLS anyway'. It's the only resolver that worked with clientid over TLS even with just a standard wildcard cert. Every other resolver throws fails, and the AGH log likewise filled with errors as above.

If anyone has any input or ideas, I'd be interested to hear (and learn) more. If this is all standard, and one **should** be getting certs for the three domains (namely `domain.xyz`, `*.domain.xyz` and `*.dns.domain.xyz`, then can we update the wiki to be more clear on the matter? I lost literally days and nights of time to 'fixing' this! :)

### Additional Information
Full debug log demonstrating the issue attached,from the FreeBSD test instance of AGH.
[verbose.log](https://github.com/AdguardTeam/AdGuardHome/files/9066265/verbose.log)