Add Nicolas Dular as backend 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 my work as an author and reviewer is consistent with other maintainers".

• 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.

@nicolasdular has been at GitLab for 3 years and 9 months. He started as a frontend and backend trainee maintainer when he started at GitLab in 2019 as a Fullstack Engineer in Growth, paused review activities during his year as an EM in Product Intelligence, and moved to be a backend-only trainee maintainer in September 2022 when being a Backend Engineer in Plan.

Nicolas has reviewed a total of 510 MRs and authored 274 MRs.

• Passes on context when he has further domain knowledge on how to improve the MR or make the code easier [1, 2, 3]
• With his experience as Fullstack Engineer, he also cares about the interaction and potential pitfalls between FE & BE [1, 2, 3, 4]
• Shares insights he had during code review to help other reviewers who might have the same question [1, 2, 3, 4, 5]
• Cares about potential performance pitfalls [1, 2]
• Encourages code readability and re-use existing code when possible [1, 2, 3]
• Identifies missing test cases and makes sure we're solving the problem correctly [1, 2, 3]

He tries to stick to Conventional Comment format when needed as outlined in GitLab’s guidelines to make sure the requests from the review are clear. [1, 2, 3]

As an author, Nicolas takes a lot of care to provide detailed guidelines how to test the MR by providing a step by step guide and screenshot/videos if possible [1, 2, 3, 4, 5]. During self-review, he tries to think ahead for potential questions from reviewers to shorten the required effort [1, 2, 3, 4], or asks speficic questions for reviewers with domain knowledge [1, 2, 3]

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 with the template below.
• 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.

Template call to action

SPECIALITY Maintainers, please review this proposal to make TRAINEE maintainer of PROJECT. 

* If you have blocking feedback adhering [to the documentation](https://about.gitlab.com/handbook/engineering/workflow/code-review/#how-to-become-a-project-maintainer) please share it with me via Slack.
* If you are in agreement please approve or give a 👍 on the MR

After 1 week, if there is no blocking feedback and at least 2 approvals, I will merge this MR.

Once This MR is Merged

1. Join the #backend_maintainers Slack channel
2. Ask the maintainers in your group to invite you to any maintainer-specific meeting if one exists.
3. Let a maintainer add you to @gitlab-org/maintainers/rails-backend
4. Announce it everywhere
5. Keep reviewing, start merging 🤘 😎 🤘