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/daemon/controller/auth/auth.go

@@ -656,6 +656,7 @@ func (v verifier) performAuthCheck(ctx context.Context) (
 			permsOpts = append(permsOpts, perms.WithAccountId(*userData.Account.Id))
 		}
 		parsed, err := perms.Parse(
+			ctx,
 			pair.ScopeId,
 			pair.Grant,
 			permsOpts...)