Allow namespacing of deps

### What version of rules_go are you using?

v0.38.1

### What version of gazelle are you using?

v0.29.0

### What version of Bazel are you using?

5.4.0

### Does this issue reproduce with the latest releases of all the above?

Yes

### What operating system and processor architecture are you using?

macOS on Apple silicon and Linux on x86_64

### Any other potentially useful information about your toolchain?

### What did you do?

Recently, Gazelle has bumped the version of `golang.org/x/tools` it depends on to `v0.5.0`. However, a project that I'm working on has not updated that dependency yet, and is still on an older release. Because of the way that the `go_repositories` are handled, there is no way to prevent Gazelle's dependencies leaking into my project's dependencies.

Debugging why the build was failing was made difficult: it was unclear which version of `golang/x/tools` was being used, and how it was imported, and then how to fix the problem so it didn't break the build. The resulting "solution" of carefully arranging function calls in the workspace files feels deeply fragile.

When using `rules_jvm_external`, it's possible to namespace particular sets of dependencies by importing them using different `maven_install` calls. This allows rulesets to distribute tooling that requires third party dependencies without that tooling impacting the users projects. It would be nice to be able to do the same thing with Go dependencies.

### What did you expect to see?

Gazelle's dependencies should not affect my project's dependencies.

### What did you see instead?

Quite the opposite.

No files or tests are named. Start by examining how go_repositories handles Gazelle and project dependencies, then compare the issue's referenced rules_jvm_external maven_install namespacing approach. Done means Gazelle's dependencies can be isolated so they do not affect the project's dependency versions.

Written by the indexing model from the issue text.