Before we weren’t caching current_project_ref because normally the reference to 
the current project doesn’t include the path with namespace. But now we store 
the current project in the projects reference cache to be used for the same 
filter when accessing using path with namespace of for subsequent filters executed on the cache.

The previous fix introduced another leak; as it made
Banzai::Filter::SanitizationFiler#customized? always return false, so we
were always appending two elements to
HTML::Pipeline::SanitizationFilter::WHITELIST[:elements]. This growth in
the elements array would slow the sanitization process over time.

This reverts commit 504a3b5e6f0b2e2957cf1e4d9d8eebbf32234bdb.

Use JavaScript tooltips for mentions

## What does this MR do?

- use JavaScript tooltips instead of plain title for mentions (issue, merge request, snippet, user, group, commit, commit range, milestone)

## Why was this MR needed?

JavaScript tooltips look nicer and can wrap.

## What are the relevant issue numbers?

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5261#note_13106713, fixes #21500

See merge request !5301

In Banzai::Filter::SanitizationFilter#customize_whitelist, we append
three lambdas that has reference to the SanitizationFilter instance,
which in turn (potentially) has a reference to the following chain:

context hash -> Project instance -> Repository instance -> lookup hash
-> various Rugged instances -> various mmap-ed git pack files.

All of the above is not garbage collected because the array we append
the lambdas to is the constant
HTML::Pipeline::SanitizationFilter::WHITELIST.

Do not look up commit again when it is passed to RelativeLinkFilter

## What does this MR do?

Use `context[:commit]` in RelativeLinkFilter instead of looking up commit using `context[:ref]`.

## Why was this MR needed?

Even though the commit object was already passed, unnecessary I/O is done to retrieve the commit object.

## What are the relevant issue numbers?

Fixes #20026

See merge request !5455