[Umbrella]: Separate authentication from TLS across Beats, Logstash and Kibana

Today the per-role *_security flags bundle two independent concerns — TLS (encryption) and authentication (credentials) — into a single boolean. beats_security and logstash_security turn on both at once, so you cannot encrypt without authenticating (or vice versa), and turning the flag off silently drops the credentials too. Elasticsearch already keeps the two apart (elasticsearch_security = the security/auth master, elasticsearch_http_security = HTTP TLS) and is the reference model.

Goal: split each client role's flag into two independent axes, each taking its default from a shared master via a plain variable default (no set_fact, overridable per role):

elasticstack_authentication → *_authentication   (credentials)
elasticstack_tls            → *_tls              (ssl.*, verification_mode, CA)

The old beats_security / logstash_security / kibana_security flags are removed.

Secure by default (both on). Guard the insecure combination collection-wide with a preflight assert: whenever authentication is required but TLS is off, fail unless elasticstack_allow_insecure_auth: true — otherwise credentials travel in cleartext (only acceptable on loopback / a trusted segment, which Elastic's "minimal security" explicitly allows).

Children (one PR each):

• #527 Masters + guard (elasticstack_authentication, elasticstack_tls, elasticstack_allow_insecure_auth)
• #528 beats: beats_security → beats_tls + beats_authentication
• #529 logstash: logstash_security → logstash_tls + logstash_authentication
• #530 kibana: remove kibana_security (ES connection follows Elasticsearch; keep kibana_tls)

Note: Elasticsearch is intentionally NOT split. There authentication and transport TLS are inseparable — Elastic mandates transport TLS when security is enabled — so elasticsearch_security stays the security master and elasticsearch_http_security the (optional) HTTP-TLS sub-flag.

Breaking → 2.0.0. Related: #513 (Beats SSL groundwork, 1.0.0), #506 (least-privilege Beats user = the auth credential).

Start by reading the existing role variables and the Elasticsearch security flags, then trace how the Beats, Logstash and Kibana roles consume their current security settings. Done means the work is divided across the listed child issues, with independent authentication and TLS defaults and a collection-wide insecure-authentication guard matching the stated behavior.