fix: return groups user has access to in group payloads

[shreddedbacon]

General Checklist

• Affected Issues have been mentioned in the Closing issues section
• Documentation has been written/updated
• PR title is ready for inclusion in changelog

Database Migrations

• If your PR contains a database migation, it MUST be the latest in date order alphabetically

As identified in uselagoon/lagoon-cli#288 (comment) Users in groups with multiple roles (eg owner, developer etc) may not be able to view their project-group allocations via the cli, because the checks performed in Lagoon don't manage to marry the user groups and project groups successfully. This will manifest as the following:

$ lagoon list project-groups -p lagoon-demo
There are no groups for project 'lagoon-demo'
GROUP ID	GROUP NAME	ORGANIZATION 

instead of
$ lagoon list project-groups -p lagoon-demo
GROUP ID                            	GROUP NAME       	ORGANIZATION 
8fc64c2a-e810-4ff1-a47e-68a1501c4ae8	lagoon-demo-group	null	

When we changed the group payload to use brief representation, this meant more information was returned in the response than what is generated when a user requests their groups. This meant that the intersection that was previously performed would fail because the project group could contain all the subgroups for roles, and the user groups would only contain the group they are a member of within the main group, the intersection would fail as the two objects were now different.

This PR changes the comparison done to still match on the parent group even if the subgroups are not all returned in a user groups query.

[tobybellwood]

This is a nice pickup

R.Intersection is overly specific here, given the two fundamentally different payloads. Doing a user<>project compare on bare group ids works better.

Tested locally ok.