Feature: setting `AWS_ROLE_SESSION_NAME` to pod name

**What would you like to be added**:

I would like the webhook to also attach a `AWS_ROLE_SESSION_NAME` envvar to the mutated pods. The downward API can be used to inject `metadata.name` as the actual value, so each pod reliably gets its own name, but other approaches are reasonable too.

**Why is this needed**:

Currently, AWS does not know the identity of the *Pod* assuming the role, just the *ServiceAccount*. So when multiple pods are doing actions it's nearly impossible to correlate CloudTrail events with an individual Pod, which would be useful when following application logs or other debugging activities.

Consider this CloudTrail event:

```json
{
"eventVersion": "1.08",
"userIdentity": {
"type": "WebIdentityUser",
"principalId": "arn:aws:iam::[redacted]:oidc-provider/[redacted]:sts.amazonaws.com:system:serviceaccount:frontend:api",
"userName": "system:serviceaccount:frontend:api",
"identityProvider": "arn:aws:iam::[redacted]:oidc-provider/[redacted]"
},
"eventTime": "2021-04-17T08:42:34Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRoleWithWebIdentity",
"userAgent": "aws-sdk-nodejs/2.802.0 linux/v14.15.1 callback",
"requestParameters": {
"roleArn": "arn:aws:iam::[redacted]:role/kubernetes/frontend/api",
"roleSessionName": "token-file-web-identity"
},
"responseElements": {
"provider": "arn:aws:iam::[redacted]:oidc-provider/[redacted]",
"subjectFromWebIdentityToken": "system:serviceaccount:frontend:api",
"audience": "sts.amazonaws.com",
"assumedRoleUser": {
"assumedRoleId": "AROA[redacted]:token-file-web-identity",
"arn": "arn:aws:sts::[redacted]:assumed-role/api/token-file-web-identity"
}
},
[redacted]
}
```

There's a whole bunch of identifiers there, none of which know more from Kubernetes beyond the namespace and service account. The session name defaults to `token-file-web-identity` which is the NodeJS SDK's behavior, while I believe other SDKs (such as golang) have a different default string there.

Now let's inject `AWS_ROLE_SESSION_NAME` via https://github.com/danopia/amazon-eks-pod-identity-webhook/commit/2ec3516b840e08257cb58d4694123e55bc06eefe and these particular fields change:

```json
{
"requestParameters": {
"roleArn": "arn:aws:iam::[redacted]:role/kubernetes/frontend/api",
"roleSessionName": "api-d59cf9bbc-pnmds"
},
"responseElements": {
"assumedRoleUser": {
"assumedRoleId": "AROA[redacted]:api-d59cf9bbc-pnmds",
"arn": "arn:aws:sts::[redacted]:assumed-role/api/api-d59cf9bbc-pnmds"
}
},
}
```

Now STS is informed about the pod name and CloudTrail activity can be correlated with individual pods 😄 in this case `api-d59cf9bbc-pnmds`

**Considerations**:

1. Individual deployments can already set this envvar directly if desired. I suggest that the Webhook perform this mutation because I see very little reason to _not_ supply a custom session-name.
1. If some cluster operators don't want this, then it would need to be feature gated. I patch I linked above (based on a quite-old git history) does not have gating and thus I didn't file a PR with it as-is.
* Given that any existing value is honored, I can't see how this would be a breaking change. Perhaps if an IAM policy grants/denies based on the default value of SessionName, which just _sounds_ brittle.
1. Perhaps `namespace/pod` would be more useful, or even `namespace/pod/container`; however the downwards API won't be useful for that. I've been happy with just podname.
1. Perhaps STS's very new `SourceIdentity` field is a better place for this. I don't see how it can be set during a `AssumeRoleWithWebIdentity` call, and this would probably involve an SDK change which is much more of an ask.

The issue does not name a file or test; begin at the webhook's pod-mutation logic and compare the linked commit for the proposed behavior. Verify that an existing AWS_ROLE_SESSION_NAME remains honored and that the completed mutation supplies a pod-name-derived session name when it is absent.

Written by the indexing model from the issue text.