Consistently indicate "runner type" using the alert component

Background

Runners can be different types according to their scope: instance_type, group_type, project_type. It's important for admins to identify clearly the runner type they manage.

Additionally, the role of maintainers/owners of groups is that of "administrators" of their group runners.

Problem

We are using to inconsistent ways to convery the runner type to administrators or maintainers.

1) admin edit	2) group maintainer/owner view	3) group maintainer/owner edit (not even there)

Proposed solution

1. frontend Use the same component:alert , type info on all these screens to provide supplemental information to the user in regards to the current context of their Runner.
2. https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-alert--text-links
3. The alert should not be dismissable.
4. Technical Writing The copy should provide users with a link to the documentation.
5. Remove the top-left "blue/green" square from 2) group maintainer/owner view, add it to the top of the maintainer view and edit screens to consistency.
6. Add the alert to the 3) group maintainer/owner edit view.

UI Copy

Technical Writing team to review the copy of the following scenarios:

• This runner processes jobs for all unassigned projects. If you want a runner to build only specific projects, restrict the project in the table below. After you restrict a runner to a project, you cannot change it back to a shared runner. [Learn more]
• This runner processes jobs for all projects in its group and subgroups. [Learn more]
• This runner processes jobs for assigned projects only. You cannot make this a shared runner. [Learn more]

Technical Info

• this change can help me reduce the amount of code in the frontend and have a single way of displaying the runner type.
• app/assets/stylesheets/pages/runners.scss could be completely removed by removing code from the 2) group maintainer/owner view.

Out of scope / For follow up

We could update the appearance of the callout more easily once we use the same code to present it in all places, and then replace it with a more appropriate banner or alert -> or something better! This may need a few more UX inputs later on.