Add guest scope to group_member

What does this MR do?

Related to customers-gitlab-com#2374 (closed)

This backend MR adds a guests scope to GroupMember so that customers-gitlab-com#2374 (closed) can be taken care of: on the GitLab new subscription page, we need to know whether some members are guests to adjust the price of a Ultimate license accordingly (guest seats don't count when purchasing an Ultimate license).

Once this MR goes out, a frontend MR will have to levarage the new guest_count in order to adjust the number of seats to purchase (see screenshots in customers-gitlab-com#2374 (closed))

Explain plan

SQL query for Group.find(9970).members.where(access_level: ::Gitlab::Access::GUEST).count (Group.find(9970) is gitlab-org):

SELECT COUNT("members".*) FROM "members" WHERE "members"."type" = 'GroupMember' 
AND "members"."source_id" = 9970 AND "members"."source_type" = 'Namespace' 
AND "members"."requested_at" IS NULL AND "members"."access_level" != 5 AND "members"."access_level" = 10

 Index Scan using index_members_on_source_id_and_source_type on public.members  (cost=0.56..263.86 rows=1 width=172) (actual time=1668.136..3152.500 rows=1 loops=1)
   Index Cond: ((members.source_id = 9970) AND ((members.source_type)::text = 'Namespace'::text))
   Filter: ((members.requested_at IS NULL) AND (members.access_level <> 5) AND ((members.type)::text = 'GroupMember'::text) AND (members.access_level = 10))
   Rows Removed by Filter: 1296
   Buffers: shared hit=92 read=1116 dirtied=56
   I/O Timings: read=3118.835

Time: 2.475 ms
  - planning: 0.274 ms
  - execution: 2.201 ms
    - I/O read: N/A
    - I/O write: N/A

Shared buffers:
  - hits: 1206 (~9.40 MiB) from the buffer pool
  - reads: 0 from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

(Something that may skew these results is that fact that I ran that same query with EXPLAIN without COUNT beforehand, I'm not sure).

Does this MR meet the acceptance criteria?

Conformity

• 📋 Does this MR need a changelog?
  • I have included a changelog entry.
  • I have not included a changelog entry because this is a developer-facing change.
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

Related to customers-gitlab-com#2374 (closed)