Fix up the fuzz helper tool

[chiphogg]

The most pressing issue is that right now, it makes //...:all
nightmarishly slow. It basically adds about a minute or two after all
the tests finish running, just to build (and not even run) this target.
(This utility is extremely compiler intensive!) The easy fix is to add
a manual tag.

While I'm at it, I might as well stop using gtest as a shortcut to get
an executable. This was never really that much of a shortcut to begin
with --- it's just a lazy decision I made N months ago when I started
working on this, and I never felt like writing a main function. I was
going to add the comments as suggested in #461 to explain why we're
using gtest, but it was easier to just stop using gtest.

[geoffviola]

Thanks for optimizing the workflow.

Do you see the test as more of an integration test? More specifically, when should fuzz/quantity_runtime_conversion_check.cc be run?

I can see that there are assertions, but it doesn't use the GTest framework. Why is that?

[chiphogg]

I see it as a tool we will want to run manually when we're making updates to the overflow and truncation checkers. It can act as a "source for unit test ideas", too: if it finds any failures, we should capture them as "vanilla" unit tests in the appropriate places.

The reason we're not using the GTest framework (anymore) is that it's not a test per se, just more a tool to explore the boundaries and look for edge cases.