Define the collection-wide variable naming schema #542

Problem

Variable names in the collection follow no single documented schema. Same concept, different
words (_pass / _pw / _password / _passphrase), mixed boolean forms (_enable 6x vs
_enabled 2x), negative booleans (no_*, disable_*), a typo (indicies), and names that do
not say what the value is (elasticstack_password is the elastic user's password,
elasticstack_initial_passwords is a file path). Without a written schema, every issue that
renames a variable has to re-decide the rules.

Want

Agree on one naming schema and document it in CONTRIBUTING. This issue only defines and
documents the rules; applying them is a separate issue.

Schema (proposed)

1. Prefix - <role>_ for role-owned variables, elasticstack_ for stack-wide ones (read by

   = 2 roles). Which variable belongs where is decided in [Feature]: Move single-role variables out of the elasticstack meta role #485 / Adopt an internal-variable naming convention (_ / __) and keep internals out of argument_specs #495, not here.

2. Internals - __<role>_<name> for register / set_fact, _<role>_<name> for vars/
   (see Adopt an internal-variable naming convention (_ / __) and keep internals out of argument_specs #495).
3. Credentials - _password for an account credential, _passphrase for something that
   protects a key or keystore. Never _pw, never _pass.
4. Booleans - positive polarity only, no no_* / disable_*.
5. Boolean suffix - _enable everywhere. It is an instruction to the role, consistent with
   the existing manage_* family.
6. Word order - <prefix>_<subject>_<attribute>, e.g. ..._repos_enable, not
   ..._enable_repos.
7. Paths - the name carries _file / _dir / _path.
8. Spelling - correct English (indices, not indicies).
9. Units - put a unit in the name only when type: and the description in
   argument_specs.yml do not already carry it. Example: *_cert_expiration_buffer needs no
   _days suffix because the spec declares type: int and the description says "in days".

Scope

• Agree on the rules above
• Document them in CONTRIBUTING