Go: tag test-only deps with EnvTesting so --include-unused-deps works

[zlav]

Overview

The --include-unused-deps flag is documented as opting in to "all deps found, instead of filtering non-production deps." On Go projects today, this flag has no effect — test dependencies are dropped at the graph-building stage in Strategy.Go.GoListPackages and never carry any environment label, so there is nothing left to filter back in.

This PR changes buildGraph to also walk the TestImports of each main-module package, tagging those packages (and their transitive packageDeps) with EnvTesting. Existing shouldPublishDep filtering in Srclib.Converter already strips EnvTesting-only deps from the upload, so default behavior is preserved; --include-unused-deps now lets these deps through, matching the flag's documented behavior on other ecosystems.

Production traversal still runs first, so any module reachable from both production and test code keeps its EnvProduction label (and full prod subtree) and ends up published.

Acceptance criteria

• Running fossa analyze on a Go project produces the same upload as before — test-only deps are excluded by default.
• Running fossa analyze --include-unused-deps on a Go project now includes test-only deps in the upload.
• Test-only deps appear in the graph tagged with the testing environment; deps reachable from both production and test code stay tagged production (and are published as production).

Testing plan

Automated:

1. cabal test unit-tests --test-options='--match="Graphing deps with go list -json -deps all"' — the existing testPackages fixture already declared a testMod test dep that was being silently dropped. The expected graph now asserts it appears as a direct EnvTesting dependency, and that the transitive test-of-a-test (transitiveTestMod) is still excluded (we don't recurse into non-main packages' TestImports).

Manual sanity check a reviewer can run:

1. cd into any Go project that has a non-trivial test-only dependency (e.g. anything pulling in github.com/stretchr/testify only from _test.go).
2. fossa analyze --output and confirm test deps are NOT in the source unit.
3. fossa analyze --include-unused-deps --output and confirm test deps ARE now present with the testing environment.

Risks

• The test traversal short-circuits when it hits a vertex already added by the production traversal. That vertex still gets an additional EnvTesting label appended (because label runs outside the unless existsAlready guard), but the test-subtree below it is not re-walked. Reviewers should sanity-check that this is OK: in practice, if the production traversal already added the vertex, every transitive dep below it has already been added with the right labels too, so re-walking would produce no new edges.
• I intentionally do not recurse into the TestImports of non-main packages. Go does not pull a dependency's test imports into your test binary, so they shouldn't appear in your bill of materials. Worth a second pair of eyes on that judgement call.
• No change to Gomod-based or other fallback Go strategies. GoListPackages is the modern, primary path; the older tactics already had their own (different) handling of test scope and are out of scope here.

Metrics

Not easily tracked from the CLI side. The right place to notice an impact is the FOSSA UI surfacing the additional test-environment deps on uploads that pass --include-unused-deps.

References

• Originating user report: --include-unused-deps on a Go project does not surface test deps.
• Prior commit that explicitly excluded test deps from the graph: bb5e4d23 ("ANE-891 exclude test deps").

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/. — Behavior of --include-unused-deps is documented in the existing subcommands reference; the flag's documented intent already matches the new behavior, so no docs change is required.
• If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is. — N/A
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top. — Added under ## 3.17.6.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. — N/A
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md. — N/A; no flag surface change.