More granular `securityContext` for Executor Containers

# Summary

The Executor Pod has multiple different containers (`init`, `wait`, etc), some of which require different permissions (`securityContext`) than others. Depending on the type of Execution (e.g. `resource`), the required permissions can be different as well

## Details

Most of this seems to come after the [lock down of `resource` pods](https://github.com/argoproj/argo-workflows/pull/8657#issuecomment-1119794432) in #8657.

That feature changes the default `securityContext` [for `resource` pods](https://github.com/argoproj/argo-workflows/blob/b0f0c589e626650ca01a635f773af983e213fbec/workflow/controller/workflowpod.go#L601) and also adds [a carve out](https://github.com/argoproj/argo-workflows/blob/b0f0c589e626650ca01a635f773af983e213fbec/workflow/controller/workflowpod.go#L611) for the `init` and `wait` container of a `resource` executor, as those cannot have a `readOnlyRootFilesystem`.

_But_, one can only configure a [single `securityContext`](https://github.com/argoproj/argo-workflows/blob/b0f0c589e626650ca01a635f773af983e213fbec/workflow/controller/workflowpod.go#L598) for the entire Executor. This means that if a user wants to use the `resource` type, the operator must allow `readOnlyRootFilesystem: false` in their `executor.securityContext`.

### Example

I recently noticed that the `initContainer` of a `resource` requires `readOnlyRootFilesystem: false` when I had an Executor Pod fail to start-up (and therefore fail to report any logs etc). It had an `Init:Error` like the below:

```sh
❯ kubectl -n agilgur5-test get pod
NAME READY STATUS RESTARTS AGE
agilgur5-test-wft-77gkn-2301407197 0/1 Init:Error 0 29m
agilgur5-test-wft-ls8q8-2301407197 0/1 Init:Error 0 18m
```

And checking the status of the Pod, the `initContainer` had an error: `message: 'open /tmp/manifest.yaml: read-only file system'`.

# Use Cases

1. Ability to lock down different containers and `resource` types of the Executor
1. Least privilege permissions per container and type
1. Not giving overly broad permissions due to "lowest common denominator" of Executor requirements, instead of more granular permissions

---

**Message from the maintainers**:

Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

Start in workflow/controller/workflowpod.go at the linked securityContext handling around lines 598-611, and review the lockdown changes in #8657. Trace how the Executor Pod creates its init and wait containers and how resource executions differ. Done means users can configure least-privilege security contexts per container and execution type without the current lowest-common-denominator setting.

Written by the indexing model from the issue text.