Make `key` optional in CommitStatus resources

[gnunn1]

In the current design the user must provide a key field in the various CommitStatus resources and this is used to match keys listed in activeCommitStatuses and proposedCommitStatuses in the PromotionStrategy resource.

I feel like this key field is mostly redundant as I am always setting the key to be the same as the name. If I change the name I need to change the key so within the CommitStatus it's not particularly DRY.

As a result I would like to see the key field made optional and if not specified then the name of the CommitStatus is used as the key. This would need to be implemented in a way that doesn't trigger a diff when using Argo CD to apply CommitStatus resources, i.e. the controller should not set the .spec.key field to the name field automatically however either using it implicitly or setting a .status.key field would be fine.

[seanl-circle]

I think name would be too prone to collision, e.g. we have ours setup as:

kind: PromotionStrategy
metadata:
  name: app1
spec:
  proposedCommitStatuses:
  - check-a
  - check-b
---
kind: ACommitStatus
metadata:
  name: app1
spec:
  key: check-a
---
kind: BCommitStatus
metadata:
  name: app1
spec:
  key: check-b

Which scales to any number of applications and makes it easy / consistent to both find the CS and configure it for an app.

[crenshaw-dev]

If we made CommitStatus keys referenceable only in the same ns, that would mitigate the collision problem. We made them global at first thinking that platform teams would create CommitStatuses in one ns to be consumed by PromotionStrategies in another ns. But it looks more likely that platform teams are going to provide _CommitStatus resources for other teams to use in their own namespaces. So their might be no need for cross-ns references.