Allow more complex maps in launcher's securityContext than just key-value pairs

Description

This is a followup to https://github.com/rstudio/helm/issues/753#issuecomment-3773835161.

Other job.tpl files may need a similar fix. This is for Workbench which has the same pattern:
https://github.com/rstudio/helm/blob/c6c1b08b849af5c4fbfbf90119fee6eb27cb69fc/charts/rstudio-workbench/files/job.tpl#L133-L146

Through issue #753 and PR #755, we were able to identify an issue where our launcher jobs either ignore more complex mappings like adding an appArmorProfile or seccompProfile to launcher.templateValues.pod.securityContext or result in an error in executing the template when the launcher runs.

While this hasn't come up as an issue with a customer for Workbench yet, since this section of the job.tpl in the Workbench chart matched the bad code in Connect, I wanted to get it flagged for review.

There are two potential issues with this section of code:

1. The current method for templating the securityContext section does not allow for more complex mapping structures in the values.yaml than key-value pairs currently. Our code is currently:
   https://github.com/rstudio/helm/blob/c6c1b08b849af5c4fbfbf90119fee6eb27cb69fc/charts/rstudio-workbench/files/job.tpl#L141-L146
   but I would expect this to fail similarly to what we saw in Connect in a situation where the you have more than key-value pairs in your values.yaml:

securityContext:
  appArmorProfile:
    type: RuntimeDefault
  seccompProfile:
    type: RuntimeDefault
  capabilities:
    drop:
      - ALL
  allowPrivilegeEscalation: false
  privileged: false

Example error from Connect issue: "json: cannot unmarshal string into Go struct field PodSecurityContext.spec.template.spec.securityContext.appArmorProfile of type v1.AppArmorProfile"

2. The second issue is that the mergeOverwrite only happens if .Job.container.supplementalGroupIds exists.
   https://github.com/rstudio/helm/blob/c6c1b08b849af5c4fbfbf90119fee6eb27cb69fc/charts/rstudio-workbench/files/job.tpl#L133-L140
   Essentially, the $templateData.pod.securityContext is getting ignored if {{- if .Job.container.supplementalGroupIds }} is false as it is in this example. This bug makes everything run without error, but the pod level securityContext wasn't being correctly applied.

Potential fix

I believe the following replacement for that section of code could fix both these issues. First, by changing the range function to uses toYaml instead when expanding the $securityContext mapping. And second, moving the mergeOverwrite line out of the .Job.container.supplementalGroupIds if statement and into the $securityContext if statement instead.
Original: https://github.com/rstudio/helm/blob/c6c1b08b849af5c4fbfbf90119fee6eb27cb69fc/charts/rstudio-workbench/files/job.tpl#L133-L146
Replacement:

      {{- if .Job.container.supplementalGroupIds }}
        {{- $groupIds := list }}
        {{- range .Job.container.supplementalGroupIds }}
          {{- $groupIds = append $groupIds . }}
        {{- end }}
        {{- $_ := set $securityContext "supplementalGroups" (cat "[" ($groupIds | join ", ") "]") }}
      {{- end }}
      {{- if $securityContext }}
      {{- $securityContext := mergeOverwrite $securityContext $templateData.pod.securityContext }}
      securityContext:
        {{- toYaml $securityContext | nindent 8 }}
      {{- end }}

My notes for testing this on Connect can be found at https://github.com/rstudio/helm/pull/755#issuecomment-3819494888 if it is helpful. I'm just not sure if I'll get a chance to verify this on Workbench in a timely manner, so I wanted to make sure this was flagged for review.

Start with charts/rstudio-workbench/files/job.tpl at lines 133-146 and compare the referenced Connect fix and testing notes in PR #755. Verify that nested securityContext mappings render correctly and that the pod-level context is applied even when supplementalGroupIds is absent.