Instrumentation layer implementation

What does this MR do and why?

Related to https://gitlab.com/gitlab-org/architecture/gitlab-data-analytics/design-doc/-/issues/53 and #510075 (closed)

This MR is a proposal for the first iteration on Instrumentation layer. For simplicity at this stage Ive looked at using InternalEvents tracking and add AI Tracking as an example. AI Tracking is choosen because currently it has a similar signature.

The idea of the proposal is to abstract events using facade (InstrumentationLayer class in this example). Calling the track_event will trigger InternalEvents tracking by default.

In addition to InternalEvents, events owners can add any amount of custom tracking classes which can process events further if needed.

Using Facade would also let us to implement custom logic related to routing events. For example, AI Tracking event's from API endpoint shouldn't be sent to Snowplow, which mean we would pass send_to_snowplow: false is AITracking is in the tracking_classes list etc.

AI Tracking events should be sent from GitLab instance, so this one will remain unchanged

Event config example

# ---
# description: Tracks when Web IDE is viewed
# internal_events: true
# action: web_ide_viewed
# etc....
# tracking_classes:
# - Gitlab::Tracking::AiTracking

Custom tracking class has to implement a track_event method with the signature as:

# ---
#  def self.track_event(event_name, additional_properties: {}, **kwargs)
#    # ...
#  end
# ---

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.