Aggregated roles for ducks should distinguish admin, edit, view.

/area API
/kind cleanup
/kind feature

Kubernetes has some built-in cluster roles for Namespace admin/editor/viewer that allow folks to curate what resources show up in each with labels like:
```
rbac.authorization.k8s.io/aggregate-to-admin: "true"
```

We have a similar problem for consumption of our assorted Duck types, which is that some consumers only need to view, and others need to patch.

I think that we should probably define and adopt a convention similar to the Kubernetes one for folks looking to define ACL fragments as we have/are.

cc @n3wscott @vaikas

Start by reviewing the existing Duck types and ACL fragments, then compare their current aggregation behavior with Kubernetes' admin, editor, and viewer role convention. Done means the project has an agreed convention that clearly distinguishes view, edit, and admin access for Duck consumers and documents how ACL fragments should use it.

Written by the indexing model from the issue text.