Validate that Secrets Manager secret ARNs contain the random suffix that AWS appends

[tomelliff]

As per the docs, AWS appends a suffix with a hyphen followed by 6 random characters to the end of every Secrets Manager secret:

Secrets Manager includes six random characters at the end of the secret name to help ensure that the secret ARN is unique. If the original secret is deleted, and then a new secret is created with the same name, the two secrets have different ARNs because of these characters. Users with access to the old secret don't automatically get access to the new secret because the ARNs are different.

We've seen issues where people forgot this suffix on the ARN in an IAM policy and then the caller fails to retrieve the secret. What compounds this is that AWS returns an error including the name of the secret instead of the ARN which strips the random suffix which then means you can spend a bunch of time looking at the IAM policy and the error and not see what's wrong with it. Here's a censored example of the error returned by AWS:

botocore.exceptions.ClientError: An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::1234567890:assumed-role/role_name/session_name is not authorized to perform: secretsmanager:GetSecretValue on resource: secretname because no identity-based policy allows the secretsmanager:GetSecretValue action

It would be good to have a lint rule for secrets manager secret ARNs (expanding on the existing aws_secretsmanager_secret_policy_invalid_secret_arn rule) that makes sure that there is either an appropriate hard-coded suffix matching that secret's ARN or a wildcard that would cover it.