Support Vault as secrets provider #108
Description
When using Vault for managing secrets in a Kubernetes cluster, one would usually want to use the Vault secrets operator. However, there are sometimes limitations in Helm charts that require injecting secret values in places that the Vault secrets operator could not (e.g. as an input that is used to template a longer secret value such as a configuration file), or when no secret reference can be specified.
For this purpose, it should be possible for Nyl to provide secrets via a Vault instance instead of a SOPS file. We should aim to design this in a secure fashion to be compatible in a multi-tenant environment where a single ArgoCD repo-server (and thus Nyl plugin container) is used to deploy applications owned by many teams.
Assuming we solve the arbitrary code execution that still needs to be addressed aside (see #48), we can trust the user input to Nyl's templating engine to the extend that they can not elevate their privileges and in return trust in Nyl to issue a workload identity according to the application that is rendered when invoked via ArgoCD.
This workload identity (asserted via a JWT) can then be configured in Vault to be trusted and assigned permissions as required to successfully render the manifests of a template, specifically for access to Vault secrets.
When running outside of ArgoCD, it would use the Vault identity obtained locally via vault login instead.