feat(eks): allow providing an existing IAM role to ServiceAccount with POD_IDENTITY

[letsgomeow]

Issue # (if applicable)

Closes #37299.

Note: This PR is the aws-eks (v1) counterpart of #37388 (aws-eks-v2).
If possible, please review and merge #37388 first, as both PRs share the same design
and reviewing v2 first will help validate the approach before applying it to v1.

Reason for this change

When using ServiceAccount with IdentityType.POD_IDENTITY, there was no way to
provide an externally-created IAM role. The construct always auto-generated a new role,
making it impossible to use a pre-existing role (e.g., one managed by a separate stack
or created outside CDK).

Description of changes

Added an optional role?: IRoleRef property to ServiceAccountOptions in aws-eks.

• When role is provided with IdentityType.POD_IDENTITY, the given role is used for
  the CfnPodIdentityAssociation instead of auto-generating one.
• When role is omitted, behavior is unchanged (a new role is auto-generated).
• Providing role with IdentityType.IRSA (or the default) throws a ValidationError
  at construction time, since IRSA requires a cluster-specific OIDC trust policy that
  cannot be set up on an external role.
• The role property accepts IRoleRef rather than IRole, following CDK's Enhanced L1
  direction. Since IRole extends IRoleRef, all existing IRole values (e.g., iam.Role,
  iam.Role.fromRoleArn()) are accepted without any breaking change.
• The ServiceAccount.role getter and related IPrincipal members (assumeRoleAction,
  grantPrincipal, policyFragment) were changed from readonly properties to getters
  so that construction succeeds even when an L1 CfnRole is passed; accessing sa.role
  on a CfnRole-backed ServiceAccount throws a descriptive error.
• The existing Fargate + POD_IDENTITY guard (throw Error(...)) is preserved in v1,
  since aws-eks supports FargateCluster and Pod Identity is not compatible with Fargate.

Describe any new or updated permissions being added

No new IAM permissions are introduced. When the caller provides an existing role, the
trust policy on that role is their responsibility.

Description of how you validated changes

• Added 6 unit tests to service-account.test.ts covering:
  • Provided role ARN is used in CfnPodIdentityAssociation (no auto-generated role)
  • ValidationError is thrown when role is specified with IRSA identity type
  • ValidationError is thrown when role is specified with default identity type
  • sa.role getter returns the provided L2 role as-is
  • ServiceAccount construction succeeds with an L1 CfnRole, but sa.role getter throws
  • sa.role getter returns auto-generated role when no role prop is provided
• Added integration test integ.eks-pod-identities-external-role.ts covering:
  • Externally-created role passed via the role prop (new behavior)
  • (Existing integ.eks-pod-identities.ts is unchanged to avoid snapshot churn)
• All existing unit tests pass without modification.
• Integration test passed in ap-northeast-1.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license