Adds templating functionality to new participant email

What does this MR do and why?

Contributes to External participants are notified when added a... (#299261 - closed)

Epic: Participants in Service Desk (&3758)

❗ This feature is hidden behind the feature flag 🎏 issue_email_participants. It's enabled on gitlab.com and is scheduled to be enabled by default for 17.0.

External participants are users on a ticket or issue without a GitLab account and can only interact with the work item via email. They can automatically be added from the Cc header or manually using quick actions and need to be notified that they're now part of the conversation.

This MRs adds the capability to add a custom template for the new_participant email. It uses the same functionality like the thank_you and new_note email. If no template is provided it uses the default template. It also refactors spec/mailers/emails/service_desk_spec.rb so we can reuse templating specs for all three emails.

This feature consists of two MRs:

1. ✅ Adds Service Desk new participant email (!150706 - merged) which adds the email with default text
2. 🎯 This MR which adds the functionality to configure a template for this email

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

We'll use a regular issue and add external participants to it to keep everything super simple and focus on the functionality of this MR. I'd like to walk you through two cases:

1. No template is used, default template will be send
2. Template has been added, so template will be used and placeholders resolve

Let's go 🚀

1. (Skip, only use if emails don't appear) If you haven't set up incoming_email or service_desk_email for email ingestion, please add this to your gitlab.yml file in the development: section. Please restart GDK with gdk restart:

   incoming_email:
     enabled: true
     address: "incoming+%{key}@example.com"

   This will allow you to see the Service Desk section in the settings and generate project-specific email addresses. You won't be able to ingest real emails, but we don't need that here.

2. Select an existing project (where you can add files) or create a new project.

3. Create a new issue and browse to the detail view.

4. Add a comment to add a new external participant like this (please note the quick action name will change with !151776 (merged) to /add_email)

   /add_email default@example.com

5. Now open letter opener (http://127.0.0.1:3000/rails/letter_opener) and you should find a new participant email to default@example.com. If they don't show up 😟 a gdk restart might help. In my installation some background jobs are stuck until I restart. Maybe that helps 👍

6. Now browse to the project page and press . to open the Web IDE.

7. Create the folder .gitlab/service_desk_templates and the file new_participant.md in that folder.

8. Add the following content to the file to test all placeholders:

   **This is a custom new participant email template.**
   
   These placeholders should be populated:
   
   Issue Id: %{ISSUE_ID}
   
   Issue path: %{ISSUE_PATH}
   
   Issue URL: %{ISSUE_URL}
   
   Unsubscribe URL: %{UNSUBSCRIBE_URL}
   
   Issue Description:
   
   %{ISSUE_DESCRIPTION}
   
   Placeholders that should not be populated but shouldn't raise an error:
   
   Note text:
   
   %{NOTE_TEXT}

9. Commit the changes

10. Go back to the issue and add another participant using this comment content:

    /add_email template@example.com

11. In letter opener, you should see another new participant email but this time using the template.