Building with go-fuzz-build / build for libfuzz

### What version of rules_go are you using?

```python
http_archive(
name = "io_bazel_rules_go",
sha256 = "886db2f8d620fcb5791c8e2a402a575bc70728e17ec116841d78f3837a09f69e",
strip_prefix = "rules_go-9bb1562710f7077cd109b66cd4b45900e6d7ae73",
urls = ["https://github.com/bazelbuild/rules_go/archive/9bb1562710f7077cd109b66cd4b45900e6d7ae73.tar.gz"],
)
```

### What version of gazelle are you using?

```python
http_archive(
name = "bazel_gazelle",
sha256 = "7fc87f4170011201b1690326e8c16c5d802836e3a0d617d8f75c3af2b23180c4",
urls = [
"https://storage.googleapis.com/bazel-mirror/github.com/bazelbuild/bazel-gazelle/releases/download/0.18.2/bazel-gazelle-0.18.2.tar.gz",
"https://github.com/bazelbuild/bazel-gazelle/releases/download/0.18.2/bazel-gazelle-0.18.2.tar.gz",
],
)
```

### What version of Bazel are you using?

1.0.0

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

N/A

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

Linux AMD64

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

### What did you do?

I'm trying to find the ideal way to integrate [go-fuzz](https://github.com/dvyukov/go-fuzz) with rules_go since that is the primary build tooling for our project.

Some immediate thoughts are that go-fuzz-build seems do to a fair bit of modification to the source files for instrumentation. See [buildInstumentedBinary](https://github.com/dvyukov/go-fuzz/blob/8cb20381268133974b070fff8f404435b3d189c1/go-fuzz-build/main.go#L507:19), [instrumentPackages](https://github.com/dvyukov/go-fuzz/blob/8cb20381268133974b070fff8f404435b3d189c1/go-fuzz-build/main.go#L695:19) and [instrument](https://github.com/dvyukov/go-fuzz/blob/8cb20381268133974b070fff8f404435b3d189c1/go-fuzz-build/cover.go#L25:6) in particular. Additionally, it provides a main file entrypoint that conforms to the target API. (llvm libfuzz or go-fuzz API). I've spent some time recently trying to understand the bazel toolchains, providers, transition rules, etc, but the solution here isn't clear and normal sources for information turn up empty. It looks like this hasn't been attempted for rules_go, from what I could find.

My specific use case is to compile for libfuzz, so I was imagining a rule like:

```python
# go_fuzz_library uses go-fuzz-build
# - Instrument all go sources up to this target (note: this modifies the source of all dependent source files)
# - Wrap provide an entrypoint that wraps and calls Fuzz([]byte) int
# - Compile as c-archive to be used by libfuzzer
go_fuzz_library(
name = "png",
srcs = ["png_fuzz.go"],
libfuzz = True,
)

# This target generates a go binary linked as a c-archive.
# Something like bazel-out/png_fuzz.a
```

Ideally, this could also integrate with gazelle such that any file with the API matching the following would automatically generate build rules with the necessary toolchain and constraints for go-fuzz.

```go
// +build gofuzz

func Fuzz(input []byte) int
```

@jayconrod do you have any suggestions or ideas about how to integrate this?
Maybe as a go toolchain? Not sure what is the right direction here.

Start by reading the linked go-fuzz functions buildInstrumentedBinary, instrumentPackages, and instrument in main.go and cover.go to understand the required source instrumentation and entrypoint. Then examine the rules_go toolchains, providers, and Gazelle integration points mentioned in the issue; done would be a supported go_fuzz_library that builds a libfuzzer-compatible c-archive, with optional automatic rule generation.

Written by the indexing model from the issue text.