Move Dependency Scanning analyzers documentation

What does this MR do?

Move the valuable content from the Dependency Scanning analyzers docs page and remove the remainder. For more detail on why these changes are being made, see Remove Dependency Scanning Analyzers doc page (#387521 - closed).

Changes include:

• Move "Gemnasium analyzers data" to the Secure stage's development documentation. Why? The intended audience is anyone contributing to dependency analyzers, not users.
• Move the description of dependency detection into a new section of the main Dependency Scanning page, named "Dependency detection".
• Move the description of the dependency scanning analyzers into a new section of the main Dependency Scanning page, named "Dependency analyzers".

Remove the following content:

Page section	Action	Notes
Using a custom Docker mirror	Delete	SECURE_ANALYZERS_PREFIX is mentioned in Offline deployments and in Configuring Dependency Scanning.
Disable specific analyzers	Delete	DS_EXCLUDED_ANALYZERS is documented in Configuring Dependency Scanning.
Disabling default analyzers	Delete	DS_EXCLUDED_ANALYZERS is documented in Configuring Dependency Scanning.

Note: This MR creates a new page, which will need to be added to the docs site's left navigation. That must be done in a separate MR as the docs site's code is contained in a separate project.

Related issues

Remove Dependency Scanning Analyzers doc page (#387521 - closed)

Screenshots

Gemnasium analyzer data

Dependency detection

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding or changing the main heading of the page (H1), ensure that the product tier badge is added.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.