[ANE-2600] Support multi line godebug and tool directive statements.

[zlav]

Overview

Closes #1571

godebug, toolchain, and tool all support multi-line formatted config options. We only support. I outlined this in a previous PR that added initial support but had to move on to other things.

module main

go 1.24.0

tool (
	github.com/bufbuild/buf/cmd/buf
	github.com/wadey/gocovmerge
)

Acceptance criteria

• godebug, toolchain, and tool all support multi line config options.

Testing plan

1. Add correct tests and ensure they pass
2. Build the CLI locally and run it on an example go.mod file that has these multi line comments.

I modified an existing go project (terraform) but you could do any repo or scan the test file if you'd like.

Risks

I can't think of any for this PR

References

Add links to any referenced GitHub issues, Zendesk tickets, Jira tickets, Slack threads, etc.

Example:

ANE-2600: Implement multi line toolchain support

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/.
• 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.
• 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.
• 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. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.

[csasarak]

This looks good. I'd just go through the comments and make sure they are addressing why/how rather than just describing what code is doing.