fix: problem detecting stdlib modules when using toolchains

[adamconnelly]

If the pkg.Module is nil, it's either part of the stdlib or it's not something that go-licenses can analyze correctly. Let's just skip modules like this instead of reporting an error.

The problem with the existing check is that it assumes that stdlib packages will have source files under build.Default.GOROOT. But if the module you're trying to analyze has a toolchain directive in its go.mod file that differs from the version of Go installed, the package will have a path outside of this directory.

I think we could possibly also remove the code that checks for a specific prefix based off the GOROOT, but I wasn't 100% sure of that so I've left it in for now. I figure it doesn't do any harm (other than add a bit of confusion for future potentially).

Reproducing the problem is pretty simple:

1. Install some version of Go (e.g. 1.24.1).
2. Create a project with a toolchain <go-version> directive in the go.mod file where that version is different to your installed Go version (e.g. 1.24.2).
3. Try to run go-licenses.

The crossplane project referenced in #302 actually has an example of this in their go.mod file (presumably the cause of the problem).

I think this should resolve the following issues:

• Bring back support for non go modules projects to v1.1+ #128 (at least some of the causes).
• Flags stdilb as "does not have module info" when on go 1.21.X #244.
• E0918 error for stdlib imports: "Package bytes does not have module info" #302.
• Fails to run with go 1.N.P go.mod syntax #324.

[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.