Allow for adding new artifacts to an existing occurrence

[alexashley]

Along with the work in #3, this closes #1

This is to account for workflows where an artifact is built and pushed to a registry in a lower environment and then retagged and pushed to a registry in a production environment. This is common at larger companies that want to restrict who can deploy production artifacts, but still want to allow for fast iteration in lower environments.

Add a build occurrence:

curl  \
  --url http://localhost:8083/v1alpha1/builds \
  --header 'Content-Type: application/json' \
  --data '{
	"commitId": "639550538727a298ed0757cdf8d1526d65eb5328",
	"repository": "https://github.com/rode/collector-build",
	"artifacts": [
		"ghcr.io/rode/collector-build@sha256:12345"
	]
}'

Update with the prod artifact:

curl --request PUT \
  --url http://localhost:8083/v1alpha1/builds \
  --header 'Content-Type: application/json' \
  --data '{
	"existingArtifact": "ghcr.io/rode/collector-build@sha256:12345",
	"newArtifact": "ghcr.io/rode/collector-build@sha256:PROD"
}
'

If there are multiple occurrences that match the artifact, the oldest is used. We could potentially allow for multiple to updated if there's a use case for that.

[alexashley]

I'll open a grafeas-elasticsearch issue to track this, but this field mask path is actually invalid, because details is a oneof field, it shouldn't appear in the mask path at all (same reason that it isn't serialized when converting a proto to text or json).

However, the utils library we use in grafeas-elasticsearch ignores the mask if we don't specify the oneof field name. We attempted to fix this, but it's a bit of a pain to do correctly, since there's no built-in support for merging proto messages in Go with a field mask (but there is for other languages).

See this issue for more info (trying not to have GH auto-reference it since it's closed):

https://github.com/mennanov/fieldmask-utils/pull/15

[mrparkers]

nitpick: I'd move this after the err check, since this won't be useful if err != nil as res will be nil anyways.

[RobertKelly]

Are we sure we want earliest? Is most current the most valid? HA... Maybe it shouldn't happen but I bet we'd want the latest one.