Instrument error tracking metrics

What does this MR do and why?

Related issue: #345053 (closed)

This adds metrics for tracking the count of unique users who:

1. Visit /error_tracking
2. Visit /error_tracking/:id/details

As a bonus, this also swaps the parent class of ErrorTracking::BaseService to ::BaseProjectService, per https://docs.gitlab.com/ee/development/reusing_abstractions.html#service-classes.

How to set up and validate locally

1. Enable the feature flag

   Feature.enable(:track_error_tracking_activity)

2. Open a project with error tracking configured
   1. Settings under project > Settings > Monitor > Error tracking
   2. Create a new error via the configured error-emmitting app (you can set up https://gitlab.com/gitlab-examples/ops/incident-setup/everyone/tanuki-inc locally to emit errors to your project)
3. Navigate to Monitor > Error Tracking
4. Open an error detail view
5. Each of the following unique user counts should eq 1:

    Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: ['error_tracking_view_list', 'error_tracking_view_details'], start_date: Date.current.beginning_of_week, end_date: Date.current.next_week)

   Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'error_tracking_view_list', start_date: Date.current.beginning_of_week, end_date: Date.current.next_week)

   Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'error_tracking_view_details', start_date: Date.current.beginning_of_week, end_date: Date.current.next_week)

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.