Fix stdlib detection across Go toolchain versions

[Ahmetshbzz]

Summary

• resolve GOROOT from the active go command used for package loading
• classify standard-library files relative to the active GOROOT/src
• reject path-prefix collisions and preserve the unsafe special case
• add regression coverage for binaries built with a different Go toolchain root

Problem

isStdLib currently reads build.Default.GOROOT, which belongs to the toolchain that compiled the go-licenses binary. When that prebuilt binary scans a module through a different or auto-downloaded Go toolchain, packages.Load returns standard-library files from the active toolchain GOROOT. The paths no longer match, so standard-library packages are treated as third-party packages without module metadata.

This reproduces the Package ... does not have module info failures reported in #302 and #335.

Verification

• go test ./licenses ./internal/...
• go vet ./...
• built the patched binary with -ldflags "-X runtime.defaultGOROOT=/tmp/go-licenses-build-toolchain" and ran go-licenses csv ./... with Go 1.26.6; no standard-library module-info errors were emitted
• go test ./... reaches the existing E2E suite but locally has an unrelated golden drift for golang.org/x/sys (golang.org/x/sys versus golang.org/x/sys/unix)
• current local golangci-lint reports 15 pre-existing findings outside this change

Fixes #302
Fixes #335

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Ahmetshbzz]

I have completed the Google Individual Contributor License Agreement. The CLA check still appears to show the earlier failed invocation; please let me know if any additional action is required on my side.