go_shared_library

So we have had a few posts complaining about go_test binary sizes recently, especially in remote_cache + RBE context.
One obvious solution is what we are cooking in remote-apis repo, where we attempt to apply Content Defined Chunking to those binaries.
But that solution would take a while to roll out to different cache/rbe server implementations and Bazel.

I was thinking that we could offer folks a second solution: dynamically link the go test binaries.
The idea is to introduce a go_shared_library rule which works something like this (rough poc)

```python
go_shared_library(
name = "sharedlib_shared",
srcs = ["sharedlib.go"],
importpath = "github.com/bazelbuild/rules_go/tests/core/linkshared/sharedlib",
target_compatible_with = ["@platforms//os:linux"],
)

go_test(
name = "sharedlib_test",
srcs = ["sharedlib_test.go"],
linkshared = "on",
shared_deps = [":sharedlib_shared"],
target_compatible_with = ["@platforms//os:linux"],
deps = [":sharedlib_shared"],
)
```

This is similar to cc_shared_library where the library will be linked as an .so file and later-on dynamically linkable to the test binary.
Underneath, this uses cmd/link -linkshared flag to link the final binary.

With this, monorepo can carve out multi-part binaries (the dynamically linked binary with several .so shared libs) for better cache hits, in RBE or in a container image layout

Start with the rough go_shared_library and go_test example in the issue, then read how cc_shared_library provides a comparable model and how Go's cmd/link -linkshared option behaves. Use the sharedlib.go and sharedlib_test.go scenario to define the rule and linking behavior, with dynamically linked test binaries and .so shared libraries as the completion criteria.

Written by the indexing model from the issue text.