cc_library dependency chain leads to wrong `-l` flag in go_binary.

### What version of rules_go are you using?
0.26.0

### What version of gazelle are you using?
None - not relevant

### What version of Bazel are you using?
4.0.0

### Does this issue reproduce with the latest releases of all the above?
Yes - AFAICT v0.26.0 is the latest release for rules_go, and v4.0.0 is the latest release for bazel.

### What operating system and processor architecture are you using?
x64 windows.

### Any other potentially useful information about your toolchain?
Running cgo code with Window's mingw.

### What did you do?
Having a dependency chain: `cc_library` -> `cc_library` -> `go_binary` uses the wrong link flag:

```
cc_library(name = "cc1", srcs = ["lib1.cc"])
cc_library(name = "cc2", srcs = ["lib2.cc"], deps = [":cc1"])
go_binary(name = "bin", srcs = ["bin.go"], cdeps = [":cc2"], cgo = True)
```

I've setup a minimal reproducible repo in https://github.com/rubensf/rules-go-cgo-issue. Those are all empty `.cc` and `.go` files, so this seems to be independent of the actual file content.

Building "bin" seems to use the wrong link flags:
```
ERROR: C:/src/testpr/BUILD.bazel:8:11: Linking liblib2_4a72131949.so failed: (Exit 1): gcc failed: error executing command cd C:/users/rubensf/_bazel_rubensf/rckt63al/execroot/test
SET PATH=c:/tools/msys64/mingw64/bin
SET PWD=/proc/self/cwd
SET RUNFILES_MANIFEST_ONLY=1
c:/tools/msys64/mingw64/bin/gcc -shared -o bazel-out/x64_windows-fastbuild/bin/liblib2_4a72131949.so
-Wl,-rpath,$ORIGIN/_solib_x64_windows /../ -Lbazel-out/x64_windows-fastbuild/bin bazel-out/x64_windows-fastbuild/bin/_objs/lib2/lib2.o -llib1_4a72131949 -Wl,-S -lstdc++
Execution platform: @local_config_platform//:host
c:/tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -llib1_4a72131949
collect2.exe: error: ld returned 1 exit status
```

It tries to link lib1: `-llib1_4a72131949`, but it can't find it.

On the execution log, you can see that bazel correctly identifies the [lib1 as an input](https://github.com/rubensf/rules-go-cgo-issue/blob/main/out.json#L299), but the correct name of the lib is `_lib_ lib1_4a72131949`.

### What did you expect to see?
I'd expect to see the correct flag name included as a link option.

### What did you see instead?
Linking fails as gcc includes the wrong link flag.

Start with the minimal reproducer in rubensf/rules-go-cgo-issue and its BUILD.bazel chain: cc1 depends into cc2, which is listed in go_binary's cdeps. Compare the link command and the lib1 input shown in out.json; done means the generated -l option uses the library's correct name and the Windows cgo link succeeds.

Written by the indexing model from the issue text.