Allow builtin 'admin' role to manage HNC objects

The builtin 'admin' clusterrole doesn't include custom resources by
default. This change allows 'admin' to modify any HNC resource. If
granted at the cluster level, it will allow the user to administer HNC
itself (via the HNCConfiguration object); otherwise, it will allow a
user to administer the HierarchyConfiguration singleton in the namespace
(and its descendants) as well as SubnamespaceAnchors. Note that this
will *not* allow that user to change the _parent_ of that namespace
without permissions in the root of its tree (see user guide for more
details).

Tested: before this change, I gave the 'admin' role to the default
service account in 'foo' and ran the following command:

```
k hns create bar -n foo --as system:serviceaccount:foo:default
```

Result:
```
Could not create subnamespace anchor.
Reason: subnamespaceanchors.hnc.x-k8s.io "bar" is forbidden: User "system:serviceaccount:foo:default" cannot create resource "subnamespaceanchors" in API group "hnc.x-k8s.io" in the namespace "foo"
```

After this change, the same command passes.

incubator/hnc/config/rbac/hnc_admin.yaml

@@ -0,0 +1,18 @@
+
+---
+# This role is intended to be used by *humans*, and is aggregated to the
+# builtin 'admin' ClusterRole. By default, 'admin' doesn't get permissions
+# to custom resources (see issue #1341).
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: admin-role
+  labels:
+    rbac.authorization.k8s.io/aggregate-to-admin: "true"
+rules:
+- apiGroups:
+  - hnc.x-k8s.io
+  resources:
+  - '*'
+  verbs:
+  - '*'

incubator/hnc/config/rbac/kustomization.yaml

@@ -1,6 +1,7 @@
 resources:
 - role.yaml
 - role_binding.yaml
+- hnc_admin.yaml
 - leader_election_role.yaml
 - leader_election_role_binding.yaml
 # Comment the following 3 lines if you want to disable