Move information to the incidents page

Start by excising the info from alert management and moving it to
the incident management page.

doc/operations/index.md

@@ -35,7 +35,7 @@ using metrics and logs, and promote the critical alerts to incidents.
 Are your alerts too noisy? Alerts configured on GitLab metrics can configured
 and fine-tuned in GitLab immediately following a fire-fight.
 
-- [Manage your external alerts](../user/project/operations/alert_management.md) and [manage Incidents](../user/incident_management/index.md) in GitLab.
+- [Manage alerts and incidents](../user/incident_management/index.md) in GitLab.
 - [Configure alerts for metrics](metrics/alerts.md#set-up-alerts-for-prometheus-metrics-core) in GitLab.
 - Create a [status page](incident_management/status_page.md)
   to communicate efficiently to your users during an incident.

doc/user/project/integrations/generic_alerts.md

@@ -116,7 +116,7 @@ In GitLab versions 13.2 and greater, GitLab groups alerts based on their payload
 When an incoming alert contains the same payload as another alert (excluding the
 `start_time` and `hosts` attributes), GitLab groups these alerts together and
 displays a counter on the
-[Alert Management List](../operations/alert_management.md#alert-management-list)
+[Alert Management List](../../../operations/incident_management/index.md#alert-management-list)
 and details pages.
 
 If the existing alert is already `resolved`, then a new alert will be created instead.