Handle AppRole's role_id and secret_id as Kubernetes secrets

**Is your feature request related to a problem? Please describe.**

I would like to deploy an application to Kubernetes (K8s) that supports secret retrieval using the AppRole method. My application currently stores all the necessary secrets in memory, and I prefer not to alter this setup by passing the secrets in ENV vars. The primary objective is to prevent the exposure of secrets, even if the container becomes compromised.

Currently, I use Gitlab CI/CD to get both the role_id and secret_id, subsequently saving them in a Kubernetes secret each time I deploy a new version of the application. The application then accesses these credentials via environment variables (ENV vars) to retrieve the secrets on its own. It's worth noting that, as per the AppRole configuration, the secret_id becomes invalidated at some point.

By following this approach, I ensure that sensitive information remains concealed and is not exposed in ENV vars or configuration files within the container.

**Describe the solution you'd like**

Similar to the VaultStaticSecret kind we currently have, we could introduce a new kind called something like VaultAppRoleSecret.

Given that the AppRole method's objective is to invalidate/destroy the secret_id once the application is initiated, we would need to trigger a rotation each time a new pod is launched. While I don't know about the specific implementation details, one possible approach could involve triggering the rotation of the secret_id stored in the Kubernetes secret whenever a pod restarts.

What do you think?

Start by reviewing the existing VaultStaticSecret kind and how the operator manages Kubernetes Secrets, then examine the AppRole role_id and secret_id lifecycle described here. Done means defining and implementing an agreed VaultAppRoleSecret design that handles rotation when pods restart, with tests covering the expected Kubernetes Secret behavior.

Written by the indexing model from the issue text.