Ensure trial status popover events include gitlab_experiment context

Resolves #342182 (closed); Also related to #335331.

What does this MR do?

Fixes an issue where no FE events were getting tracked because our experiment adds data to Gon after it has already been rendered out to the layout (so our experiment does not show up in the window.gon.experiment object in the browser).

Rendering process

1. app/views/layouts/application.html.haml renders
2. app/views/layouts/_head.html.haml renders when invoked by application.html.haml
3. Gon Rendering is then invoked

However, our code in the trial_status_popover_data_attrs helper in trial_status_widget_helper.rb is invoked after this process due to 🤷 (the fact that our experiment is essentially being run at the layout level?), which causes window.gon.experiments not to have its value. However, if we have a partial which is rendered later in application.html.haml, the data for the experiment is there and we are able to pass it from the backend to the frontend.

Codepath I’m solving for

1. Render some view which uses the Group left-side navigation sidebar
2. Renders the application layout
3. Renders the page layout with nav set to 'group'
4. Renders layouts/nav/sidebar/group
5. Instantiates the Sidebars::Groups::Panel menu builder
6. Instantiates the TrialExperimentMenu menu panel
7. Renders the layouts/nav/sidebar/group_trial_status_widget partial
8. Calls the trial_status_popover_data_attrs helper method
9. Checks if the popover should start_initially_shown?
10. Which runs the experiment

At this point, the experiment data should exist in the frontend. But if you look for it in window.gon.experiment you will not find it. With this MR, you can find it in window.gl.experiments because that partial is rendered as late as possible in the layout.

Follow-ups for work not done here

• #344686 - Prove the need to use window.gl.experiments instead of window.gon.experiment
• #344684 - Deprecate usage of window.gon.experiment for GLEX data

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• I have tested this MR in all supported browsers, or it's not needed.
• I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.

Security

Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team