Better document how to enable Auto Monitoring

What does this MR do?

This should clean up and streamline the process of getting your application working with Auto Monitor.

It should solve the following question

If I'm using k8s and AutoDevOps, which of the documentation options do I use, and which pieces do I need to set up?

As an MVC, I'll try to solve the following that Amelia pointed out:

if I'm using k8s and AutoDevOps, which of the documentation options do I use, and which pieces do I need to set up?

With the knowledge I have now:

1. I'd go to https://docs.gitlab.com/ee/topics/autodevops/#auto-monitoring
2. Be directed to read the requirements https://docs.gitlab.com/ee/topics/autodevops/#requirements, from which I need all.
3. First is GitLab Runner. I know you can install it separately in its own server, but if I use k8s inside GitLab, I can install it as a manged app. This is not mentioned.
4. Next is the base domain. There's a bunch of docs here, but there's nowhere mentioned that this can be automatically set up by installing the managed app Ingress.
5. Next is Kubernetes. We mention its version, although you don't have to worry if you're installing it via GitLab. The load balancer is also mentioned under Kubernetes, which is the same as Ingress (mentioned in base domain).
6. Finally, Prometheus. We mention the response metrics, but they feel out of place. They should be in the Prometheus doc. There's nowhere mentioned that you can install it via the managed apps.
7. After all that, I go again to https://docs.gitlab.com/ee/topics/autodevops/#auto-monitoring, only to find out that I don't even need to follow the 3 steps outlined there to get the initial metrics that are provided out of the box!

This MR will try to solve all of the above.

Related issues

Closes #31709 (closed).

Author's checklist

• Follow the Documentation Guidelines and Style Guide.
• If applicable, update the permissions table.
• Link docs to and from the higher-level index page, plus other related docs where helpful.
• Apply the documentation label.

Review checklist

All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Documentation Guidelines and Style Guide.

1. Primary Reviewer

• Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.

2. Technical Writer

• Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable DevOps stage.

3. Maintainer

1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
2. Ensure a release milestone is set and that you merge the equivalent EE MR before the CE MR if both exist.
3. If there has not been a technical writer review, create an issue for one using the Doc Review template.