Draft: Use GitLab username as the slug for team member YAML files

Why is this change being made?

See the proposal at: #34494

How to review this

It might be easier to review this locally with this Git command:

git diff origin/master... -- ':!data/team_members'

So we don't read changes inside data/team_members. They're done by running ./scripts/update-slug-to-gitlab.rb and we can always regenerate.

Implementation notes:

0. We don't rename the team member files yet. Ideally they should be named the same as GitLab username, but preferably we do that in a next iteration if we ever want to do that, because that's asking for a lot of conflicts.
1. We leave the current slug checks in places, so the filenames must still be unique. This is to reduce changes as well. Ideally, we should change this to check GitLab username instead, and also check the filename if desired.
2. Godfrey Sullivan is the only person who doesn't have gitlab. I gave it a fake GitLab username godfrey-s so things still run smoothly. Previously, slug must exist because it's the filename, and we can assume it must be there. Changing it to be using gitlab means we need to make sure gitlab exists as well. This might be fine if we also move the files so filenames are based on gitlab, but we're not there yet. Faking is easier for this iteration.
3. We might want to give fake usernames to vacancies as well? Need to dig deeper for this.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

---

Closes #34494