If the `imageswap_pull_secret_source_name` is set, the kubeconfig is loaded in `init_imageswap()` and
creates a Kubernetes CoreV1Api client. It makes a copy of the secret in the k8s object passed in,
then reads in the source secret in the imageswap-system namespace to generate a new secret in the
target namespace from it’s data. This generated secret is then created or updated in the target
namespace.

Added Kubernetes to the Pipfile for the imageswap image and updated the Pipfile.lock accordingly.

Added a new ClusterRole, `imageswap-write-secrets` in deploy/install.yaml to give get and update
permissions to `imageswap-shared-pull-secrets` and create permissions for `secrets`. Also added a new
ClusterRoleBinding, `imageswap-write-secrets-crb` for the `imageswap-write-secrets` ClusterRole.

Added `add_image_pull_secrets` method to add imagePullSecrets to a k8s object. This method is used
in `mutate()` to add imagePullSecrets (if applicable) to a pod or a pod template. The method takes in
2 arguments, the modified_spec and the namespace of the target object. There is a side-effect in this
method of creating/updating the secret `imageswap-shared-pull-secrets` in whichever namespace was
targeted.

Added 2 new environment variables:

IMAGESWAP_PULL_SECRET_DESTINATION_NAME: name of secret to be created in the target namespace (set to
`imageswap-shared-pull-secrets` so that it will line up with the permissions write/read/delete
permission granted on just that secret in other namespaces)
IMAGESWAP_PULL_SECRET_SOURCE_NAME: name of secret in imageswap-system namespace to copy (the secret
stored at this value will need to be pre-populated by users)

The logic of creating/updating the pullSecrets in a given namespace on mutation of a pod will handle
the majority of cases, since any new pods get the most recent copy of the credentials. However, if a
pod were to get rescheduled to a new node (for some reason) and the credentials that were originally
synced into the namespace have since expired, then a ImagePullBackOff could result. This could be
fixed with an additional watcher on the secrets stored at `IMAGESWAP_PULL_SECRET_SOURCE_NAME`. However
for now it could also be fix by users updating the `IMAGESWAP_PULL_SECRET_SOURCE_NAME` in the
`imageswap-system` and applying the same update to any `imageswap-shared-pull-secrets` across all
namespaces.