Docs: Update GitLab Duo Use Cases - examples, prompts

What does this MR do?

The GitLab Duo Use Cases (former: Examples) documentation helps customers learn and practice in their Duo adoption journey.

Over the months, many more examples, code generation prompts, and use case stories have been developed from customer feedback. @dnsmichi (me) is the maintainer of the documentation page.

This MR is the first iteration with "static" code examples, and linking all existing blog tutorial resources together. Future MRs will contain recorded Duo Coffee Chat sessions, and more use cases for customer requests (for example, I could not finish a Java Spring Boot example in time). Tracked in #467725

The changes are as follows:

1. Added Use case stories
   1. Explain, test and refactor a Kotlin application
   2. Get Started with PowerShell
   3. Root Cause Analysis use cases
      1. Blog post, linking to Duo Challenges as exercises to learn https://about.gitlab.com/blog/2024/06/06/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/
2. Update/add Code generation prompts
   1. Add tested generated source code from the prompts into most examples, to make the examples look more real. Just comments can mean anything.
   2. Aim to add prompts for all Duo supported languages in the prompts project https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/tree/main?ref_type=heads#code-generation-prompts
   3. C code generation prompts - NEW 🌱
   4. C++ code generation prompts - added: Create a CLI application that acts as HTTP client
   5. CSS code generation prompts - NEW 🌱
   6. HTML code generation prompts - NEW 🌱
   7. Kotlin code generation prompts - NEW 🌱
   8. PowerShell code generation prompts - NEW 🌱
   9. Scala code generation prompts - NEW 🌱
   10. Shell scripts code generation prompts - NEW 🌱
   11. TypeScript code generation prompts - NEW 🌱
3. Formatting fixes for the headings

Related issues

Docs: Add more GitLab Duo Use Cases and resources (#467725) • Michael Friedrich

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• 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.