[EKS] [RemoteAccessConfig.sourceSecurityGroups]: Allow the use of cross-account VPC-peered security group sources

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**

Attempting to assign an cross-account VPC-peered security group to the `RemoteAccessConfig.sourceSecurityGroups` renders an error indicating _"One or more security groups in remote-access is not valid!"_

This failure scenario is not disclosed via the [RemoteAccessConfig documentation](https://docs.aws.amazon.com/eks/latest/APIReference/API_RemoteAccessConfig.html#AmazonEKS-Type-RemoteAccessConfig-sourceSecurityGroups) and seems to contradict the [Security Group Rules documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html) which states that a Source may be:

> The ID of a security group (referred to here as the specified security group). For example, the current security group, a security group from the same VPC, or a security group for a peered VPC. This allows traffic based on the private IP addresses of the resources associated with the specified security group. This does not add rules from the specified security group to the current security group.

Likewise, [VPC Peering Documentation states](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html):

> The peer VPC can be a VPC in your account, or a VPC in another AWS account. To reference a security group in another AWS account, include the account number in Source or Destination field; for example, 123456789012/sg-1a2b3c4d.

These cross-account VPC-peered Source values are defined in the format of `/` and can indeed be created / utilized as such via the AWS Console.

The EKS `RemoteAccessConfig` API should support this situation as well, and is confusing people that use the API directly, or via IaC tools, [such as Terraform](https://github.com/hashicorp/terraform-provider-aws/issues/11596#issuecomment-720731829).

**Which service(s) is this request for?**

EKS - Managed Node Plane

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

We are trying to restrict SSH ingress to our managed node plane to a particular source in a cross-account VPC peering connection.

**Are you currently working around this issue?**

Theorizing that we will need to provide a blackhole security group within the account to otherwise neutralize the default 0.0.0.0/0 SSH ingress rule, applying the SSH ingress to the less-proper control plane security group that gets applied to each Node.

**Additional context**

We first observed this in a Terraform context as well, validating that it fails upstream in the EKS API as [indicated by the `terraform-provider-aws` maintainers](https://github.com/hashicorp/terraform-provider-aws/issues/11596#issuecomment-736577097).

**Attachments**

Example TF Failure:

```
Error: creating EKS Node Group (test-cluster:test-cluster): InvalidParameterException: One or more security groups in remote-access is not valid!
{
RespMetadata: {
StatusCode: 400,
RequestID: ""
},
ClusterName: "test-cluster",
Message_: "One or more security groups in remote-access is not valid!",
NodegroupName: "test-cluster"
}
```

No repository files, tests, or implementation entry points are mentioned. Start by reviewing the EKS RemoteAccessConfig sourceSecurityGroups documentation, the referenced AWS security-group and VPC-peering documentation, and the linked Terraform issue. Done means EKS accepts cross-account VPC-peered security-group values in the stated account-id/security-group-id format and documents the supported behavior.

Written by the indexing model from the issue text.