DrvCnlMqtt: add CA pinning, mutual TLS, and revocation control

[xtim8719xCopilot]

Summary

The MQTT channel driver's UseTls option only ever called MqttClientTlsOptionsBuilder.UseTls() with no further configuration. That's fine against a broker with a publicly-trusted certificate, but there was no way to:

• trust a private or self-signed CA
• present a client certificate for mutual TLS
• control revocation-check behavior

MQTTnet itself already supports all of this (WithCertificateValidationHandler, WithClientCertificates, WithIgnoreCertificateRevocationErrors, etc.) — it just wasn't exposed through MqttConnectionOptions or the options dialog.

What's added

Four new connection options on MqttConnectionOptions, all optional and off by default (fully backward compatible — verified the sibling DrvMqttClient/DrvMqttPublisher drivers that also reference DrvMqtt.Common still build unchanged):

• CaCertFile — pins the broker's certificate chain to a specific CA file via a custom X509Chain (X509ChainTrustMode.CustomRootTrust), instead of trusting whatever happens to be in the OS trust store. This performs real chain validation against the given CA — it is not a bypass.
• ClientCertFile / ClientCertPassword — presents a client certificate (PFX) for mutual TLS authentication.
• AllowUntrustedCertificates — explicit opt-in bypass, only applied when no CaCertFile is given.
• IgnoreCertificateRevocationErrors — skips CRL/OCSP revocation checking. Useful because ScadaComm often runs as a Windows service account (e.g. LocalSystem), which can fail to complete an online revocation check — and that failure surfaces as an opaque NotSupportedException ("Specified method is not supported") with nothing indicating revocation checking was the cause.

Also improved MqttClientHelper's connection error logging: it previously logged only the wrapping AggregateException's generic message ("One or more errors occurred."), discarding the real inner exception and stack trace. It now unwraps and logs the actual cause — which is what made the revocation-check failure above diagnosable in the first place, instead of a dead-end guess.

The options dialog (FrmMqttClientChannelOptions) gains matching fields: CA certificate file / client certificate file (with browse buttons), client certificate password, and the two checkboxes. English and Russian language files updated.

Test plan

• Built DrvCnlMqtt.View.csproj and DrvMqtt.Common.csproj in Release against a clean checkout of develop, per HowToBuild.txt.
• Verified DrvCnlMqtt.Logic, DrvMqttClient.Logic, and DrvMqttPublisher.Logic (all consumers of DrvMqtt.Common) still build unchanged against the extended options class.
• Deployed to a real ScadaComm6 instance connecting to EMQX Cloud over TLS with a pinned CA cert (CaCertFile) — confirmed MqttClientHelper.Connect() succeeds and the line shows "MQTT client, connected".
• Verified the CA-pinning path rejects a connection when the presented cert doesn't chain to the configured CA (not just a blanket accept).

Note: this PR is independent of #125 (protocol version dropdown fix) — they don't depend on each other and can be reviewed/merged separately.

[2mik]

Hello,
Thank you for the pull request.
Could you add screenshots of the updated Windows forms?

[xtim8719xCopilot]