fix: handle operator crash when using workloadRef

[praddy26]

Description
This MR fixes issue #751 where restarting an Argo Rollout configured with workloadRef causes the Reloader operator pod to crash with a panic: "runtime error: index out of range [0] with length 0".

Root Cause
The issue occurs because Argo Rollouts using workloadRef reference an existing Deployment/ReplicaSet instead of defining containers directly in their Spec.Template.Spec.Containers. When the GetRolloutContainers function is called for such rollouts, it returns an empty slice since no containers are defined in the rollout template itself.

The panic happens in the getContainerUsingResource function in upgrade.go when the code attempts to access containers[0] without first checking if the slice contains any elements.

Solution
Added bounds checking before accessing the first element of the containers slice to prevent index out of range panics.

Related Issues
Closes #751

[Felix-Stakater]

Hi and thank you for your contribution!

The fix proposed will work in theory but it will only result in the error NoContainerFound being generated, since we are not actually fetching the underlying workload being referenced.

This is for sure better than the operator crashing so i think it can be implemented as-is.

For the full fix we would probably need to fetch the referenced workload and find the container to restart from there. The issue then becomes: "How do we know if a deployment is being referenced from an ArgoCD Rollout?", this is for when getting an updated Deployment, we need to know if we should ignore it and trigger the reload via the argoCD Rollout, or if we should trigger the reload based on the "raw" Deployment.

This requires some planning for how to implement it and keep track of if a resource is referenced by an argoCD rollout. We are open to ideas and PRs for sure.