[WIP] Optional support for custom default service account

[mikkeloscar]

This introduces an injection of a custom default service account named after the resource in the format: default-<kind>-<name>. E.g. if you deploy a Deployment with the name my-app the serviceAccountName used in the pod will be default-deployment-my-app if you didn't specify a custom serviceAccountName already. This is done for the following kinds: Deployment, StatefulSet, StackSet, Crobjob.

The motivation for this is that we have pods running with default service account and reading from the Kubernetes API. This is a leftover from before RBAC was introduced and the intention is that all such use cases be replaced with a custom service account as defined here: https://cloud.docs.zalando.net/howtos/service-accounts/
The problem is that since all workloads run with default service account by default, it's hard to identify those workloads that run with default AND read from the Kubernetes api. We have metrics from the audit-events: https://teapot.docs.zalando.net/application/kubernetes/#apiserver-client-visibility but the user is always system:serviceaccounts:<namespace>:default so it's hard to identify which deployment/statefulset/pods that actually is doing it.
By introducing a custom default service account for all main resource types we effectively give each deployment/statefulset/etc. their own identity which will make it simple to identify in the metrics.

The intention is to roll it out behind a flag and only enable it per cluster where there are a need for it because default service account is reading from the apiserver. There are some clusters where the default service account is bound to RBAC permissions. In those clusters we can't enable this because we would have to also change the bindings to not drop permissions (not entirely sure if it matters in practice, but would start by just looking into those specific cases).