operator-sdk: Don't override relatedImages in config CSV.

@ryantking - Yeah makes sense to me. I hadn’t considered backcompat issue with the name changing. In all likelihood, there’s nothing that actually depends on that name since I know OLM and mirroring tooling ignore it. But there could be some operator author tooling that uses it.

So I’m plus +1 to that tweak, though I still think it makes sense to issue a warning about the statically defined related images. If we want to be more vague about why you shouldn’t do that, we could just say that specifying static related images is deprecated, that you should start using RELATED_IMAGE_ envs, and we’ll remove persistence of static related images is OSDK v2.

I think we should specifically recommend only the env-based related image detection. If there are csv.spec.relatedImages in the base CSV manifest, I think we should:

1. Give them the lowest precedence when choosing names or de-duping.
2. Output a warning along the lines of “we found related images in your base CSV. we preserved them in the generated CSV, but your operator is at risk for supporting disconnected environments”

So I think that logic would look like the following when comparing discovered vs base:

1. same image, regardless of whether the names differ: use the discovered name/image pair in the output.
2. same name with a different image: keep discovered name, prefix base name (with static- or base- or something along those lines).
3. name/image pair not found in discovered set: add base name/image pair to output.

I need @tlwu2013 to check my math on item 2, but it seems like you need a RELATED_IMAGE_* environment variable for each other image you expect to use so that when your bundle is built, the pipeline can correctly inject digest-based image references for every image your operator uses.