Add IssuableTitlePipeline with CodeSpanFilter

What does this MR do and why?

Closes Extend issuable title rendering to support *onl... (#599800).

This approach is deliberately minimal in degree of enhancement. I don't know if "minimum viable change" is still a Thing(tm), but it's the correct way here. We can elaborate later if we need to.

Please read the descriptions of the following MR and issue to get context on why this MR is the way it is:

• Use regular non-Markdown single line pipeline f... (!224839 - merged)
• https://gitlab.com/gitlab-org/gitlab/-/work_items/587818+ (staff-only)

The MR reverted a poorly-conceived pipeline while normalising how the rendered output was actually displayed in many areas. (There have been follow-up MRs to continue to use titleHtml where appropriate.) The issue has a discussion that brought us to the point of making the MR, with a lot of backing context, and explicit support from PSIRT, and EMs/PMs in Plan.

This MR now adds minimal but desirable functionality by building on top of the stable and secure base we've given ourselves, without overreaching (i.e. to parsing HTML, or to using a whole Markdown parser). Only the simplest code span support is added, which nonetheless should suffice for 90% of cases.

I've also corrected some dangerously misleading comments, and removed dead code found along the way.

Screenshots or screen recordings

Using the below example title:

Add new <input> with id `xyzzy`

	Before	After
Work items list
Work item view
Work item view scrolled down

How to set up and validate locally

1. Create a new work item with the following title:

   Add new <input> with id `xyzzy`

2. It should look like the "Before" images above.
3. Check out this branch, maybe restart your GDK rails-web if it's been a long day.
4. Edit the work item title, making an actual change to it somehow: add a character somewhere. If you do not do this, the render cache will not be invalidated, and you won't see any change.
5. Now you should see the after!
6. (Optional) Do a little happy jig.

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.