Improvments to fuzz_coverage

[krinkinmu]

Based on the conersation in #39030 (see #39030 (comment), #39030 (comment) and #39030 (comment)) it looks like fuzz_coverage CI target does not quite measure what we want it to measure (we want it to measure what coverage the fuzzing achieves, while what it currently measures is coverage of the initial seed without what fuzzing on top of that achieves).

I did a brief search for fuzz_coverage related open issues in the repository, but I didn't find anything open already. I'm opening this issue to consider how we can measure the covearage achieved by fuzzing (or conclude that we can't do that for some reason).

NOTE: At the moment I don't have any good suggestions on how we can actually make fuzz_coverage target more useful, since I don't have full understanding how it works, so I'm keeping this issue a bit open ended.

@phlax @yanavlasov @adisuissa

[krinkinmu]

After @adisuissa pointed out that my understanding of how fuzz coverage works is not quite correct I digged a bit more and indeed, I was wrong that fuzz coverage didn't report the coverage results with fuzzing included (see #39030 (comment) and #39030 (comment)).

That being said, there are still a few improvements that could be made to fuzz-coverage, specifically:

1. Migrate it to EngFlow from the Google RBE backends - this aligns with general direction of migrating to EngFlow, but it also allows us to give CI a bit more resources and switch to static linking for coverage.
2. Slim down fuzz coverage targets and make them build faster and with less resources, e.g., we probably don't need WASM enabled for the fuzz-coverage

So that's what I will track in this issue.

[krinkinmu]

/assign @krinkinmu