No toolchain flags are passed to the assembler in cgo mode

rules_go 0.50.1, gazelle 0.43.0.

When attempting to cross-compile https://github.com/DataDog/zstd from macOS (using the gazelle-generated BUILD files) to x86_64 Linux, we got the following cryptic linkage error:

```
ld.lld: error: /var/folders/2k/slf21zyn0pzdcpbd1mwxwv1h0000gq/T/rules_go_work-1484370210/cgo/github.com/DataDog/zstd/_x46.o: unknown file type
clang: error: linker command failed with exit code 1 (use -v to see invocation)
compilepkg: error running subcommand external/llvm_toolchain/bin/cc_wrapper.sh: exit status 1
```

After reproducing with `--sandbox_debug` and running the rules_go builder command with `-v --work`, we found that this one file was not cross-compiled:

```
file /.../rules_go_work-1419368796/cgo/github.com/DataDog/zstd/_x46.o
/.../rules_go_work-1419368796/cgo/github.com/DataDog/zstd/_x46.o: Mach-O 64-bit object arm64
```

And this was because the command run by the builder was not cross-compiled:

```
SET_A_BUNCH_OF_ENV_VARS= .... \
external/llvm_toolchain/bin/cc_wrapper.sh -c $SANDBOX_DIR/execroot/dd_source/external/com_github_datadog_zstd/huf_decompress_amd64.S -o /.../T/rules_go_work-4033279204/cgo/github.com/DataDog/zstd/_x46.o
```

This an assembly file, and is the [only one](https://github.com/DataDog/zstd/blob/06fc470c217ed173e17990d0a65a95b7d638a6ee/huf_decompress_amd64.S) built in the repository.

The expected file type would have been at least x86_64 ELF.

I haven't looked into creating a simple repro case, as it would require configuring a C cross-compiler, and disentangling the one we have from our repository is nontrivial.

Regardless, it looks like flags aren't considered in the [cgo builder](https://github.com/bazel-contrib/rules_go/blob/ffc8ff69552ce68579c7720e303da5d2174d87dc/go/tools/builders/cgo2.go#L329-L334) at all. Ideally, rules_go would plumb through the flags for the `assemble` and/or `preprocess-assemble` [cc toolchain actions](https://bazel.build/docs/cc-toolchain-config-reference#assembler-actions), and give an override in `go_library`/`binary`/`test`, although, in my experience, they tend to be the same as the C flags.

Workarounds:

- Patch rules_go to set the `sSrcs` flags to the same as the C flags in the path mentioned above.
- Patch the gazelle-generated BUILD file to contain a `cc_library` that corresponds to the cgo sources used by library, and put that in `cdeps` for the library itself.

A similar ticket is #2612, but it's asking explicitly for flags for the go assembler.

Start in go/tools/builders/cgo2.go around lines 329-334 and compare the flags used for C compilation with the assembler and preprocess-assemble cc toolchain actions. Reproduce the cross-compilation case with the DataDog zstd huf_decompress_amd64.S source and verify that the resulting object is an x86_64 ELF file rather than a Mach-O object.

Written by the indexing model from the issue text.