Preserve user and project mention original input for redactor; address bug in latter

What does this MR do and why?

Fixes `@ all` is rendered to `@ All` (#415958).

Our UserReferenceFilter and ProjectReferenceFilter are a bit special, in that they don't inherit from AbstractReferenceFilter like almost every other reference filter. (I'm guessing it's because they came first, seeing as users and projects are quite core to GitLab!)

We've done a lot of security work in recent times targeting reference filters, with most wins taking place in AbstractReferenceFilter and bubbling down to the rest. The two filters concerned here are very small and so luckily have little scope for error. The little scope they do have, however, they have exercised 😸

The two filters failed to preserve the original input text in data-original, meaning that when ReferenceRedactor does any work, the best it can do is remove the added link — the text that we produced in these reference filters when creating the canonical form links remains. This means that if you have a private group with the name Hello, if a user without access types @hello, it won't turn into a link for them, but it will show as the text @Hello (!). This is the root cause of #415958.

Project references are subject to the same issue.

This MR addresses the issue in both by including the original input in data-original (like AbstractReferenceFilter does), so the redactor can restore the original input when necessary. Specs are added throughout.

Bonus bugfix

There's an additional bug in project references which correcting this bug uncovered: they don't work correctly in link form.

It doesn't appear to be documented (?), but GitLab supports references like this:

[the issue for this MR](#415958)

Produces the following:

the issue for this MR

Note that it links correctly to the issue, with popover on hover. The same works for users:

[asherah](@kivikakk)

asherah

The same is meant to work for projects (as it does for most other kinds of reference!), but at time of writing, it does not:

[gitlab!](gitlab-org/gitlab>)

gitlab!

The fix to the linked bug made this additional bug apparent, so I addressed it along the way. Specs are added, and the same kind of cleanup was applied to the user reference filter to keep our codebase predictable and correct (as it was doing some very suspect matching on node outer HTML — let's not do that!!).

MR acceptance checklist

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