Add ability to generate deploy keys to gitRepo controller

[HappyTetrahedron]

A separate field generatedDeployKeys is added to the gitRepo spec, where deploy keys can be listed without explicitly specifying a key. The gitRepo reconciler then duplicates these entries into the deployKeys field, generating a new keypair for each entry. The keypair is stored in a newly created secret.

If a secret already exists, it is not overwritten. Information from the secret takes precedence over information in the generatedDeployKeys field (this is relevant e.g. for the key type). However, secrets are not watched separately, so modifying the secret will not trigger a reconcile. (I consider this to be more of a corner case than a feature - the secret is not supposed to be edited.)

Checklist

• Keep pull requests small so they can be easily reviewed.
• Update the documentation.
• Categorize the PR by setting a good title and adding one of the labels:
  bug, enhancement, documentation, change, breaking, dependency
  as they show up in the changelog

[simu]

I'd prefer tracking the generated deploy keys separately from externally provisioned deploy keys (I'd probably put the generated keys in .status.deployKeys and explicitly reference the associated secrets there).

Afaict, with the current approach, users could create chaos by requesting a generated deploy key named steward (if I read the code correctly, the generated key would win over the key supplied by steward, permanently breaking ArgoCD on such clusters).

[HappyTetrahedron]

Done.
Naming conflicts are still an issue - Gitlab can in theory have multiple deploy keys with the same name, but our whole update and deletion logic relies on matching keys by name so that'll fall apart. So I decided to add a prefix to all generated keys. There's still nothing stopping the user from creating a naming conflict ... but it's less likely to happen by accident like this.

[simu]

LGTM overall, didn't verify test case in detail.

Some small suggestions inline.