bug: self-signed x509 certificates with custom SAN raise MITM error

## The issue

When creating a self-signed certificate with a custom SAN, trusting it, then running the SSH3 client again raises a MITM error:
```
7:28PM ERR The server certificate cannot be verified using the one installed in /home/theo/.ssh3/known_hosts. If you did not change the server certificate, it could be a machine-in-the-middle attack. TLS error: CRYPTO_ERROR 0x12a (local): tls: failed to verify certificate: x509: certificate is valid for selfsigned.ssh3.asdf, *, not oumpah-pah.nwrd.fischernet.net
7:28PM ERR Aborting.
exit status 255
```

## Steps to reproduce

First, generate custom x509 certificates using OpenSSL:
```sh
openssl req -x509 -sha256 -nodes -newkey rsa:4096 -keyout priv.key -days 3660 -out cert.pem -subj "/C=XX/O=Default Company/OU=XX/CN=selfsigned.ssh3" -addext "subjectAltName = DNS:selfsigned.ssh3.asdf,DNS:*"
```
Then run the server using `-cert cert.pem -key priv.key` and try to log in.

The first time, the client outputs this:
```
Received an unknown self-signed certificate from the server.
We recommend not using self-signed certificates.
This session is vulnerable a machine-in-the-middle attack.
Certificate fingerprint: SHA256 jVh5A/EBAtSsfPSQS3f4G67FBLJIKAohkC+dcdLfIWA=
Do you want to add this certificate to ~/.ssh3/known_hosts (yes/no)? yes
Successfully added the certificate to /home/theo/.ssh3/known_hosts, please rerun the command
```

The second time this:
```
7:28PM ERR The server certificate cannot be verified using the one installed in /home/theo/.ssh3/known_hosts. If you did not change the server certificate, it could be a machine-in-the-middle attack. TLS error: CRYPTO_ERROR 0x12a (local): tls: failed to verify certificate: x509: certificate is valid for selfsigned.ssh3.asdf, *, not ssh3.local
7:28PM ERR Aborting.
exit status 255
```

## Expected behaviour

The client accepts the trusted certificate.

For me, this is a bug, as I explicitly trust the certificate the server presents.

## Resolution

If the SANs save are the same as the one presented, then the client should accept the certificate (although all other certificate parameters should also be taken into account, like expiry).

That should be around [line 473 in `cli/client/main.go`](https://github.com/francoismichel/ssh3/blob/96b63ccb4b7d8b44f0697462cb6db1d857c1cd5e/cli/client/main.go#L473C9-L473C9)