Add group lists to member endpoints

[charliepark]

This adds a groups field to the User view in the external API, so that when you fetch a user (or list users), you get back the list of groups that user belongs to.

This was initially prompted by console#3211, where we need to easily pull each user's groups, for determining their effective role, factoring in both their inherited role (from the silo), their assigned role (from the project), and their group memberships (from both the silo and the project). Without the changes in this PR, we calculate that by running a query for each group, then finding the group membership, then mapping it to each user. So I think this is an improvement. Downside is that it runs the additional group bundling on every user endpoint.

One question @david-crespo and I talked through a bit, though we didn't get deep into it, was whether the shape of the group should just be … a group … as opposed to what we have in this PR, which is an object of just the group name (a string) and the id (a UUID). The other elements of a Group object are the silo, which is the same as the user's silo, then the created_at and updated_at timstamps, which I'm not sure we'll use. With all of that, I think just the ID and name is fine, but I'm open to alternate takes.

[david-crespo]

My main reason for avoiding this in the past is that the group list can’t be paginated (and this is worse than other resources because it comes from the identity provider, so we don’t control how big it can get). That’s probably why you don’t see this pattern anywhere else in the API. If we really wanted to do this join API-side, maybe we could instead have an endpoint that lists all the group memberships of all users (as user ID/group ID pairs), and it would be a paginated ResultsPage. That would at least be a single call (well, one call per page, and we’d have to fetch all the pages). But it doesn’t feel like it solves the console’s problem as neatly as the change in this PR — you still have to do a bunch of work client-side to make it useful. So I lean toward not doing either one and continuing to deal with it in the console.