Support Azure DevOps vs-ssh.visualstudio.com SSH remotes as hosting provider

[Kahitar]

PR Description
This PR adds support for parsing legacy Azure DevOps SSH remotes that use the
vs-ssh.visualstudio.com host, which is still common in older repositories or corporate setups.

This PR fixes issue #2667.

Previously, even if users mapped this host to the Azure DevOps provider via
configServiceDomains, URL generation failed with:

Failed to parse repo information from url

because the Azure DevOps ServiceDefinition regex set did not include this SSH format.

Changes

• Added a new regex to azdoServiceDef.regexStrings to match:

  git@vs-ssh.visualstudio.com:v3/<org>/<project>/<repo>
  

• This allows getRepoURLFromRemoteURL to correctly extract org, project, and repo
  for these remotes.
• Added a test case to TestGetPullRequestURL verifying that mapping
  vs-ssh.visualstudio.com → azuredevops:dev.azure.com produces the correct PR URL.

Example

With this config:

services:
  'vs-ssh.visualstudio.com': 'azuredevops:dev.azure.com'

and remote:

git@vs-ssh.visualstudio.com:v3/myorg/myproject/myrepo

GetPullRequestURL("feature/new", "") now returns:

https://dev.azure.com/myorg/myproject/_git/myrepo/pullrequestcreate?sourceRef=feature%2Fnew

Why

• Many users still have remotes in this legacy format.
• This change is backward-compatible and does not affect existing supported remotes.
• It unblocks URL generation for PRs and commits without requiring users to change their remotes.
• Fixes Azure DevOps pull request #2667

Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

Thanks for this; I have no experience with this myself, so I can only trust you that this is good.

One word about TDD: that's a very good thing of course, but failing tests shouldn't be committed. We have a policy here that all commits should have green tests. My standard approach to ensure this is like this: b1facec