Add Michael Lunøe as a CDot FE maintainer

Manager Justification

It's hard to specify hard requirements for becoming a maintainer, which is why the documentation consists of flexible guidelines. Reviewers are encouraged to think of their eligibility for maintainership in the terms of "I could be ready at any time to be a maintainer as long as it is justified".

• The MRs reviewed by the candidate consistently make it through maintainer review without significant additionally required changes.
• The MRs authored by the candidate consistently make it through reviewer and maintainer review without significant required changes.
• Reach out to at least two of the maintainers privately for feedback on the reviewer. The reviewer may have some suggestions on who these maintainers could be.

• Maintainer of gitlab-org/gitlab for 3+ years.
• Working on gitlab-org/customers-gitlab-com project for 3 years, where 1 year was spent as an EM.
• Reviewed and approved 50+ MRs in gitlab-org/customers-gitlab-com (while reviewing and approving 200+ MRs in gitlab-org/gitlab).

Note: The ratio between reviewers/maintainers will change when we merge this MR. However, we actively use maintainers to also do initial reviews, so there should be no problem with this.

Links to Non-Trival MRs I've Reviewed

Here are a few reviews that stood out as non-trivial:

MR	Changes	Notes
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/8756+	+136-35	Ensuring changes are robust and tested thoroughly, involving UX to take action on UI inconsistencies. General comments around code and consistency in code base, providing guidance on abstraction when viable. Working with the contributor to make it easier to implement changes and help them prepare MRs, so they are easier to review in the future. Merged with three nit-pick comments.
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/9404+	+9-12	Caught a UX error. Removing complexity, ensuring we have sound solutions that work across all pages. Capturing missed issues.
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/7225+	+7-0	Making documentation more actionable on backend related guidance.
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/9789+	+0−197	Asking questions about impact for customers.
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/9439+	+22-2	Proposing a sound solutions to the problem that does not impact the user experience.
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/8313+	+197−4	Preventing multiple error logging and guiding to improve error handling. Providing suggestions to readable code.
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/8129+	+146−231	Standardizing the styles on our public pages.
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/9803+	+84−89	Ensuring that we have accurate documentation and helpful guides to use our tools.

Before Merging (Manager Tasks)

• Close any relevant trainee maintainer issues with a comment indicating that this merge request is being created, as (they are no longer required to become a maintainer).
• Mention the maintainers from the given specialty and ask them to provide feedback to the manager directly.
• Leave this merge request open for 1 week, to give the maintainers time to provide feedback.
• Ensure we have at least 2 approvals from existing maintainers.

Once This MR is Merged

1. Create an access request for maintainer access to gitlab-org/<project>.
2. Join the [at]frontend-maintainers slack group
3. Ask the maintainers in your group to invite you to any maintainer-specific meeting if one exists.
4. Let a maintainer add you to gitlab-org/maintainers/frontend with Owner access level.
5. Announce it everywhere
6. Keep reviewing, start merging 🤘 😎 🤘

This issue was created using this template.