IRSA credentials preferred over explicit STS session in environment variables

**Describe the bug**
When both `AWS_ROLE_ARN`/`AWS_WEB_IDENTITY_TOKEN_FILE` and `AWS_ACCESS_KEY_ID`/`AWS_SECRET_ACCESS_KEY`/`AWS_SESSION_TOKEN` are set, this library is preferring the former. This causes Vault 1.4.0+ to ignore an explicitly set access key in the environment in favor of IRSA. This seems like a bug to me. If someone has gone to the trouble of exporting the access key and session token variables from an STS session, it doesn't make sense to request new credentials with IRSA. Presumably if a user has done this, they have already used the IRSA-based credentials to call `sts:AssumeRole`.

**To Reproduce**
Steps to reproduce the behavior:
1. In a Kubernetes pod with IRSA enabled, run `aws sts assume-role` to assume an STS role in another account
2. Export the access key ID, secret, and session token as `AWS_ACCESS_KEY_ID`/`AWS_SECRET_ACCESS_KEY`/`AWS_SESSION_TOKEN`
3. Run `vault login -method=aws role=some-vault-role`
4. Receive `error looking up full ARN of entity` error

Having this be a cross-account scenario is key to getting the `error looking up full ARN of entity` error specifically, but if it isn't a cross-account role you would likely just get a failed login when the role ARN from IRSA does not match the bound ARN wildcards.

**Expected behavior**
When `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are set in the environment (and optionally `AWS_SESSION_TOKEN`), `awsutil` should ignore `AWS_ROLE_ARN` and `AWS_WEB_IDENTITY_TOKEN_FILE`. This is how `aws sts get-caller-identity` works, for example.