feat(MCP): MCP configs open with documentation links and examples

Description

This change improves the default configuration file that gets created for MCP (Model Context Protocol) servers in GitLab Duo. Instead of creating a bare-bones empty configuration, the system now generates a helpful template file with detailed comments and examples showing users how to set up their MCP servers. The template includes documentation links, explains what MCP servers do, and provides copy-paste examples for both local and remote server configurations. This makes it much easier for users to understand and configure MCP servers without having to look up documentation separately. The change also consolidates the template definition into one shared location instead of having duplicate code in multiple files.

Related Issues

Resolves: [MCP] Add documentation for how-to on MCP confi... (#2107 - closed)

How has this been tested?

Note: If you already have MCP config files created, go ahead and save them somewhere else momentarily. Testing may involve deleting MCP config files from your local machine.

1. Since VSCode has not been released with new LSP changes, check out the latest version of main on LSP and build that project locally targeted at VSCode npm run watch -- --editor=vscodde --packages all
2. Check out this branch, db/update-mcp-config-file-creator-with-docs, and build the VSCode extension locally
3. If you already have MCP config files (and have saved them somewhere else momentarily), when you open either GitLab MCP: Open User Settings (JSON) or GitLab MCP: Open Workspace Settings (JSON) will open up the previously saved MCP config file.
4. This MR changes what happens when opening a brand new MCP config file from the command palette.

• If you have both Workspace and User config files, please delete one for testing.

5. Trigger either GitLab MCP: Open User Settings (JSON) or GitLab MCP: Open Workspace Settings (JSON) and you should see commented out documentation for how MCP works at GitLab and some examples.

• If src/browser or src/common has been modified, please consider interoperability with the Web IDE. See Running the Extension in WebIDE.
• Consider an end-to-end test for significant new features that aren't covered by integration tests.

Screenshots (if appropriate)

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• None - other non-user-facing changes