fix: several resources had admin actions in the delete-data sections

[joshlartz]

The read/write/delete groups are meant to operate on data and the admin is meant to operate on the resource. I found some instances where that line was blurred incorrectly.

[skuenzli]

Hi Josh,
Thanks for preparing this PR.

There are a number of AWS IAM permissions that classify to multiple capabilities in the k9 Access Capability model so those mappings are intentional. You've identified a number of them.

The k9 Access Capability model is designed to reflect the pragmatic reality of managing permissions in AWS, Azure, and other clouds.

One of those explicit design choices is to classify a permission to multiple capabilities when the permission allows multiple operations that operators would recognize and distinguish as different capabilities. My favorite example is rds:DeleteDBCluster which both deletes the 'stateless' cluster instances and the stateful data volume. So k9 classifies rds:DeleteDBCluster as administer-resource and delete-data. By comparison the AWS 'access level' of rds:DeleteDBCluster is Write, which I think is tragically misguided.

There are a number of other intentional differences between the k9 Access Capability model and the AWS Access Level model (as well as Azure's various definitions of 'privileged').

One similarity across all the models is that once a permission is classified, we can't change how the permission is classified unless the change makes it stricter (more secure).

What issue/problem did you encounter that prompted you to issue this PR?