Build Go SDK file attrs in the exec configuration (#4650)

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

The experimental source-bootstrapped SDK
(`experimental_bootstrap_go_sdk`) emits the `go` binary, the tool
binaries, and the GOROOT `src`/`pkg` layout from a generated bootstrap
target. `go_tool_binary` runs the SDK's `go` binary in the exec
configuration — the `go` and `tools` attrs of `go_sdk` are already `cfg
= "exec"` — so that binary infers `GOROOT` from its own exec-config
path.

The remaining SDK file attrs (`root_file`, `libs`, `headers`, `srcs`)
had no configuration set, so Bazel supplied them under the target-config
path. When those inputs don't sit under the exec-config `GOROOT` the
`go` binary derives from its own location, the Go command can't find
standard-library packages such as `cmd/pack`, and the bootstrap builder
build fails.

This pins `root_file`, `libs`, `headers`, and `srcs` to `cfg = "exec"`
so the whole SDK layout lands in one consistent configuration alongside
`go` and `tools`. `package_list` is intentionally left unpinned: it is a
generated list of standard-library import paths whose contents do not
depend on the configuration.

**Which issues(s) does this PR fix?**

Small bug fix in the experimental bootstrap SDK — no associated issue.

**Other notes for review**

This only changes how the `go_sdk` rule's own inputs are configured. For
the normal downloaded SDK these attrs point at static source files, so
they resolve to the same artifacts regardless of the transition; the fix
matters for the bootstrap SDK, where the layout is generated and would
otherwise be produced under the target configuration while `go` runs
under the exec one.