Plugins built with boringcrypto SDK fail to load citing incompatible internal/crypto/boring library

Nobody has claimed this yet.

### What version of rules_go are you using?

First seen at 0.31.0. Reproduces at HEAD (1ceb5a779d3d6284487154fa6c881e3d785cdebf).

### What version of gazelle are you using?

N/A

### What version of Bazel are you using?

```
Bazelisk version: development
Build label: 5.2.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Jun 7 16:02:26 2022 (1654617746)
Build timestamp: 1654617746
Build timestamp as int: 1654617746
```

Also seen on 4.1.0-vmware (derived from 4.1.0 upstream).

### Does this issue reproduce with the latest releases of all the above?

Yes.

### What operating system and processor architecture are you using?

Linux amd64 / CentOS 7 (problem occurs in CentOS 8 too)

### Any other potentially useful information about your toolchain?

Problem occurs when using the [boringcrypto](https://go.googlesource.com/go/+/refs/heads/dev.boringcrypto/misc/boring/) releases of the go SDK, however, the problem will likely reproduce in any environment using cgo in the standard library.

### What did you do?

Build a plugin that makes use of some sort of crypto module when using the boringcrypto SDK, and try running with it. Reproduction case available at https://gist.github.com/nacl/4a7c162435e13101bc3359a5c65069db (derived from the tests in `tests/core/go_plugin`).

Problem can be reproduced simply with `bazel test //...`

### What did you expect to see?

Plugins load; tests pass.

### What did you see instead?

Tests fail. Log excerpt below:

```
--- FAIL: TestPluginWorks (0.01s)
all_test.go:21: plugin.Open("plugin"): plugin was built with a different version of package crypto/internal/boring
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
```

This problem is believed to be caused by distinct compile/link flags chosen when building the cgo parts of the go stdlib that causes the binaries compiled by the C compiler to be different. The main one of note is the use of position-independent code (`-fPIC` flag) used to build the cgo binaries in the plugin, and the lack thereof in the test binary. We have internal patches against rules_go to ensure that the flags are consistent in our local setup, which has some other interesting flags (e.g. `-Wl,-z,defs`) that may also cause differences.

The issue no longer reproduces using these flags to build the reproduction case, above:

```
bazel test --force_pic --@io_bazel_rules_go//go/config:linkmode=pie //...
```

This forces the use of position-independent code everywhere in the build. Notably, using `go build` and `go test` seem to work properly when using the boringcrypto SDK directly:

```console
> go version
go version go1.18.3b7 linux/amd64
> go build --buildmode=plugin -o plugin.so
> go test
PASS
ok foo 0.013s
```

I believe that this occurs because `go build` builds the standard library at a lower level than rules_go does currently.

Start with tests/core/go_plugin and reproduce the failure using the boringcrypto Go SDK and `bazel test //...`; compare it with the working `go build` and `go test` behavior. Investigate the position-independent and cgo-related flags described in the issue. Done means the plugin loads and the tests pass without requiring `--force_pic` or pie link mode.

Written by the indexing model from the issue text.