Fork `mail_room`, release and use our own fork `gitlab-mail_room`

The following discussion from !19186 (merged) should be addressed:

• @cablett started a discussion: (+16 comments)

  @tkuah how would I go about testing this, or figuring out where it is deployed so I can close #30070 (closed)? 🤔 Or would I close #30070 (closed) now that this MR is merged?

We need to release the mail_room functionality but that involves being dependent on the maintainer. We can base our version of mail_room on a specific SHA in the Gemfile (scratch that, we can't do that, because as @.luke mentions below, the SHA can be changed if there is a rebase on master), but there will likely be further changes depending on requirements.

Let's fork the mail_room repo, release and update our Gemfile to use our custom release with the merged PR.

See https://about.gitlab.com/handbook/developer-onboarding/#ruby-gems

Steps to follow, based on @smcgivern 's comment

• Set up https://github.com/cablett/mail_room as an up-to-date fork of tpitale/mail_room
• Set up a gitlab-mail_room project in gitlab-org as a pull mirror of https://github.com/cablett/mail_room. The rest of the steps I'll be doing on GitLab.com.
• Update the README to state the reason for the fork.
• Rename the gem in the gemspec (but not anywhere else) and merge branch to master.
• Bump the version (or downgrade it; it doesn't matter as it's a new gem).
• Build the gem and push to RubyGems.org.
• Add these owners: https://about.gitlab.com/handbook/developer-onboarding/#ruby-gems

Resulting repo: https://gitlab.com/gitlab-org/gitlab-mail-room