[Umbrella]: Collection-wide opt-in mutual TLS (client-certificate auth to Elasticsearch)

Today only #486 (Kibana→ES) covers mutual TLS. mTLS needs both halves: the server must request a client certificate (xpack.security.http.ssl.client_authentication — by default ES does not request one, security settings) AND the client must present one. Currently Logstash even ships a keystore to ES, but since ES requests no client cert it is ignored — effectively one-way TLS + password.

Add opt-in mTLS on each client→ES channel, and separate the certificate concerns in the output configs: cacert / ssl_certificate_authorities (the client verifying the server — needed for any TLS) stays on the TLS axis; the client certificate (keystore / ssl.certificate+ssl.key — mTLS-only) becomes the opt-in.

Children (one PR each):

• #537 — ES side: xpack.security.http.ssl.client_authentication enabler (server half; requires HTTP TLS)
• #538 — Beats → ES: present a client certificate (opt-in)
• #539 — Logstash → ES: keystore as an opt-in mTLS flag, split from cacert/auth
• #486 — Kibana → ES (existing, 1.2.0)

Opt-in, default off (non-breaking). Depends on the TLS axis (*_tls, #526); the client-side children depend on the ES-side enabler. The Logstash child restructures the same ES-output block as #529 → coordinate. Milestone 2.0.0 for the block-touching parts; #486 stays 1.2.0.

Start with child issues #537, #538, and #539, then review the TLS-axis dependency #526 and the Logstash coordination point in #529. Treat #486 as the existing Kibana implementation. Done means the server and each client channel support opt-in mTLS with defaults off, while preserving the stated separation between server verification and client certificates.