caddytls: add certificate operation and on-demand ask metrics

[IslamElsayed]

Part of #1683: the two counters from the agreed contract. The expiry gauge follows once the CertMagic method it needs is released (caddyserver/certmagic#413).

caddy_tls_certificate_operations_total{operation, issuer, result, error_type}
caddy_tls_on_demand_ask_total{result}

• operation is obtain or renew, and result is success or failure. On failure, error_type comes from the ACME problem type: rate_limited, challenge_failed (connection, dns, unauthorized, incorrectResponse, tls, caa) or other.
• issuer is the configured issuer's key. On a failure it's the last issuer tried, whose error is the one returned.
• The ask counter records allowed, denied or error for every call to the on-demand permission module.
• No certificate name, SAN, account or ask URL is used as a label.
• The collectors are created once per process, so counts carry across reloads, and are registered unconditionally with each config's registry.

The counters are fed by the cert_obtained and cert_failed events through onEvent, and are counted before the events app's Emit decides whether anything observes them. On ShouldEmit: CertMagic currently consults ShouldEmitFunc only for tls_get_certificate, so these events already reach onEvent either way. The tls app now reports them as wanted anyway, so the metrics keep working if CertMagic starts gating them.

Tested with unit tests, and with a caddy binary at INFO log level:

• local_certs: {operation="obtain",issuer="local",result="success"} 1
• an unreachable ACME CA: {operation="obtain",issuer="127.0.0.1:1-directory",result="failure",error_type="other"} 1
• on-demand TLS with an ask endpoint: one allowed and one denied

(I used AI assistance, Claude, while preparing this; I reviewed and tested it myself.)