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

[afeefghannam89]

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):

• [Feature]: Elasticsearch — support xpack.security.http.ssl.client_authentication (request client certs) #537 — ES side: xpack.security.http.ssl.client_authentication enabler (server half; requires HTTP TLS)
• [Feature]: Beats — opt-in client certificate to Elasticsearch (mTLS) #538 — Beats → ES: present a client certificate (opt-in)
• [Feature]: Logstash — opt-in client certificate to Elasticsearch (mTLS), split from cacert/auth #539 — Logstash → ES: keystore as an opt-in mTLS flag, split from cacert/auth
• [Feature]: Optionally support mutual TLS between Kibana and Elasticsearch #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.