Support multiple IDs in grants (#3263)

This allows specifying multiple IDs in grants via an `ids` field, which
will eventually become the normal way to specify IDs. Internally, each
grant with multiple IDs turns into multiple ACL grants each with a
single ID; to make this distinction clearer and allow for better
separation of concerns an AclGrant type has been introduced, so really
multiple IDs in a Grant turn into multiple AclGrants.

The nice thing about doing it this way is that it becomes purely a
parsing concern; no actual validation logic has changed.

For backwards compatibility with grants already stored in roles, we do
not error out if `id` is specified. However, eventually we will simply
not support grants with `id` coming via the API; they will fail API
validation, such that new grants will require the use of the updated
`ids` field.

A follow-on PR will plumb this through the service handlers/API/CLI, but
I decided to do it in separate chunks to make reviewing easier, given
that they are easily separable into the internal and external aspects of
the change.

* Add CLI/API checks around using ID in grants (#3264)

* Plumb through some contexts to remove a lot of deprecated errors (#3268)

internal/proto/controller/api/resources/roles/v1/role.proto

@@ -25,7 +25,11 @@ message Principal {
 
 message GrantJson {
   // Output only. The ID, if set.
-  string id = 1; // @gotags: `class:"public"`
+  // Deprecated: use "ids" instead.
+  string id = 1 [deprecated = true]; // @gotags: `class:"public"`
+
+  // Output only. The IDs, if set.
+  repeated string ids = 4; // @gotags: `class:"public"`
 
   // Output only. The type, if set.
   string type = 2; // @gotags: `class:"public"`