Use titleHtml where appropriate

What does this MR do and why?

Closes Emojis in work item titles are not rendered in ... (#597261) — titleHtml is the canonical, safe rendered variant of title for work items and issuables in general, so use it with v-safe-html wherever possible to ensure e.g. emojis are rendered consistently anywhere work item titles are shown.

This became the case as of Use regular non-Markdown single line pipeline f... (!224839 - merged), but as noted in that MR, there are still places where just title was used (occasionally with some hacks to e.g. manually render emoji in an ad-hoc fashion); this MR tries to round up all the stragglers.

Note that titleHtml is only safe for use with v-safe-html because it has been rendered and sanitised by the backend first. Please note that, despite its name, v-safe-html cannot be used safely with plain text, such as title — that's how we get XSS.

This MR also tightens up a few v-safe-htmls. Work item titles can contain links, such as references to other work items:

This is fine where the title is rendered without itself being a link. When it is a link (such as in a work item listing, issue board, a system note, or the "scroll to top" sticky header link when scrolled down a page), we use FORBID_TAGS: ['a'] in our v-safe-html configuration to strip any rendered links from within. This is to prevent situations like this (current master) where there's nested links, which is super-unintuitive:

We don't blanket apply the FORBID_TAGS directive, otherwise we'll lose them everywhere, such as in popovers where the title isn't linked itself (since the popover is displayed on a link):

In every place I've modified the v-safe-html configuration, it's been only used for this one purpose, so there aren't any knock-on effects. I do kinda feel that it'd be better to name the options key something like titleSafeHtmlConfig (declare intent, prevent unintended reuse and/or changes), and am super open to reviewers' thoughts on that.

Screenshots or screen recordings

I have a work item with the name entered as Henwo :fox:, a task called Henwo task :fox:. This below table scrolls!

What	Before	After
Popover
Linked items
Child items
Work item token input preview
Parent item in sidebar
Work item sidebar dropdown
Parent metadata in work item list
Ancestor bread crumb trail
Issue board card title*

*Per the screenshots, issue board card titles worked before, but only in a hacky way: it manually parsed emoji in the text title. Now we rely on the backend to render them the same everywhere and delete the special-casing in issue boards.

Known omissions:

What	Before/After	Why
Work item token input autocomplete dropdown		The matching substring(s) are highlighted; this needs to be (carefully) authored for HTML input
Work item sidebar dropdown "currently selected" in editing state		Needs gitlab-ui MR

How to set up and validate locally

1. Check out the branch.
2. Create some work items and tasks with titles containing:
   • emoji shortcodes (:rabbit:)
   • references to other work items, MRs, anything (#123)
   • backtick inline code (like `this`!)
3. Create relationships between them, and check their titles render per "After" in the above cases.

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.