ZDM-494 Make it easier to encrypt sensitive variables and remove them from intermediate files

[alicel]

This PR contains changes to:

• Make it easier for users to encrypt sensitive variables that are passed to Ansible as part of the ZDM configuration.
• Avoid storing cluster credentials in intermediate files used by the automation.

Note: encrypting variables is completely optional, and can be done using ansible-vault commands to encrypt any configuration files after populating them. With this PR:

• The cluster-related configuration is moved into a separate file (zdm_proxy_cluster_config.yml) that the user can choose to encrypt if they wish. This configuration data can be considered sensitive and rarely needs to change.
• The read mode, primary cluster and logging configuration remain in zdm_proxy_core_config.yml. These are not sensitive variables and need to change during the migration, so having them in an unencrypted file makes more practical sense.

The change is backwards-compatible. This version of the automation works even if a user provides the "old-style" zdm_proxy_core_config.yml file containing all the variables: in this case, the values in zdm_proxy_core_config.yml are used as normal (taking precedence over any value provided in zdm_proxy_cluster_config.yml, should the user populate both files).

Additionally, this PR removes the need for storing the cluster credentials into intermediate files used by the automation, therefore making the handling of these sensitive values more secure.

[alicel]

The --ask-vault-pass option needs to be passed to the run playbook command whenever an encrypted file is pulled in by the playbook, regardless of what that file actually contains. The reason for this is that Ansible cannot of course view the encrypted file, so it can't know whether its content is actually necessary or not without decrypting it and therefore needs to decrypt it in order to run the playbook.

Encrypting files is always something optional that the user explicitly chooses to do, so I don't see this as breaking backward compatibility. If the user had the old-style and the new-style files both in clear, they could run the playbook in the usual way and the old-style one would take precedence (as expected), so everything would work as before. If they decide to encrypt any file used by the playbook, they will always need to pass the --ask-vault-pass option and then the old-style file will still take precedence, if provided.