Use core `go` lib/tooling for identify package metadata URLs instead of the `Masterminds/VCS` fork

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Code improvement description

Today we fetch metadata information using `github.com/Masterminds/vcs` library:
https://github.com/dependabot/dependabot-core/blob/642f064cc2126996cfaa31f61255e49a451da6cf/go_modules/helpers/importresolver/main.go#L14-L33

However, that is a copy/paste of some code in core `go`, so we'd rather get direct access to the actual source. [Further context](https://github.com/dependabot/dependabot-core/issues/4448#issuecomment-1247317691):

> I think the code is trying to map a Go import path back to a repository so we can e.g. link to the repo in the Dependabot PR, find the CHANGELOG, link to the diff between versions, etc, etc.
> It’s not totally trivial with Go because:
> 1. they’ve got that whole vanity URL thing going on, where you have to pass `go-get=1` in to make it act like a fancy redirect to a repo
> 2. a Go import path doesn’t necessarily actually match a repo URL. For instance, I might be able to import https://github.com/go-kit/kit/tracing, but that’s not a valid URL on GitHub. The repo is [github.com/go-kit/kit](http://github.com/go-kit/kit), and the package is browsable at https://github.com/go-kit/kit/tree/master/tracing. So Go bakes in some [logic](https://github.com/golang/go/blob/95c125a44ad1a0c3e441c3214160cd7b4483e79c/src/cmd/go/internal/vcs/vcs.go#L1437) to handle that for a series of SCMs, and the Masterminds/vcs package does a [similar thing](https://github.com/Masterminds/vcs/blob/master/vcs_remote_lookup.go) too.
>
> Ideally, we’d just use whatever golang/go does, but IIRC that wasn’t importable so the next best thing was the Masterminds/vcs implementation. The Ruby code you linked to predates our usage of that Go library, and I’d guess is just a really incomplete Ruby implementation of the same thing.
> Perhaps these days a) there’s a good Ruby implementation, or b) we think the VCS list is stable enough we’d be happy to translate it to Ruby, or c) we could somehow codegen the Ruby from the canonical Go implementation? Or we just stick with that one-off Go helper?

I dug into this a little, and there's already an upstream request:
* https://github.com/golang/go/issues/18387

Where someone [noted](https://github.com/golang/go/issues/18387#issuecomment-277001616):
> This very functionality already exists, and has existed for a long time, in [`golang.org/x/tools/go/vcs`](https://godoc.org/golang.org/x/tools/go/vcs) package, under the func named [`RepoRootForImportPath`](https://godoc.org/golang.org/x/tools/go/vcs#RepoRootForImportPath).
>
> Note that it correctly resolves a vanity import path to "https://github.com/rsc/pdf", and the repo root to "rsc.io/pdf". It's the same code that `cmd/go` uses for go get, just copied to another library where it can be imported.

However, it looks like the current plan is to deprecate that library:
* https://github.com/golang/go/issues/57051

I subscribed to https://github.com/golang/go/issues/18387 and whenever it lands we should flip to that.

Start in go_modules/helpers/importresolver/main.go and trace how github.com/Masterminds/vcs provides package metadata URLs. Check the status of golang/go issues 18387 and 57051 and the x/tools/go/vcs RepoRootForImportPath entry point; done means the helper uses the supported canonical Go implementation instead of the fork.

Written by the indexing model from the issue text.