Duplicate and incorrect documentation for CKV_AWS_111 and CKV_AWS_109

CKV_AWS_111 ([write access without constraints](https://github.com/hlxsites/prisma-cloud-docs/blob/main/docs/en/enterprise-edition/policy-reference/aws-policies/aws-iam-policies/ensure-iam-policies-do-not-allow-write-access-without-constraint.adoc)) has the documentation for CKV_AWS_109 ([resource exposure without constraints](https://github.com/hlxsites/prisma-cloud-docs/blob/main/docs/en/enterprise-edition/policy-reference/aws-policies/aws-iam-policies/ensure-iam-policies-do-not-allow-permissions-management-resource-exposure-without-constraint.adoc)).

Both of these documents are wrong and make no mention of the Resource constraint (`*`) that needs to be set to specific ARNs.
The "Fix" diff for [CKV_AWS_111](https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/aws-iam-policies/ensure-iam-policies-do-not-allow-write-access-without-constraint) even shows a policy that completely passes even before removing the offending line marked with a `-`.

Also interesting is that these are both subsets of [CKV_AWS_356](https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/aws-iam-policies/bc-aws-356) which is marked as "High" severity, while these two, which check if even more dangerous things are low priority.

Can these checks be reevaluated for validity? I have found a few other checks (e.g. [CKV_K8S_356](https://docs.prismacloud.io/en/enterprise-edition/policy-reference/kubernetes-policies/kubernetes-policy-index/bc-k8s-21) with invalid, possibly AI-generated, information that does not describe the check properly, and I fear there are several others.

We are evaluating our options and would like to get all our teams using Checkov, but it is difficult to pitch when the documentation does not accurately describe the issue and the fix.

Start with the two linked AsciiDoc files for CKV_AWS_111 and CKV_AWS_109, then compare them with the CKV_AWS_356 documentation and the referenced Fix diff. Verify whether the Resource constraint and specific ARNs are accurately described, and check the severity relationship. Done means the affected documentation correctly explains each check and its fix, with any broader reevaluation scoped separately.

Written by the indexing model from the issue text.