Lazy initialization for user popovers

What does this MR do and why?

Right now user popovers are initialized synchronously in the deferredInitialisation step, which is called in the idle callback task queue. This is great for postponing main thread blocking, but it is still blocking the main thread for a noticeable amount of time. The effect is more prominent on large blame pages with hundreds or thousands of tooltips.

Here is the performance measurement of the user popover init callback on the page that is used in a GitLab Performance Tool on a high-end machine:

This MR intends to initialize user popovers on interaction in order to reduce blocking time to a minimum.

Screenshots or screen recordings

Here's a comparison of synchronous and lazy initialization done on a high-end machine on a blame page for a small file. I wasn't able to thoroughly test it on a large blame file because I wan't able to find a blame page with lots of user popovers on the default GDK installation (though I would be very thankful if you can point me to those).

Before	After

How to set up and validate locally

1. Open a blame page that contains user popovers (you can find them via the js-user-link class)
2. Measure execition time for the addPopovers function
3. Repeat the same for the master branch

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.