tools: add two fuzz harnesses to be consumed by OSS-Fuzz

[DavidKorczynski]

Adds two new fuzzing harness to increase code coverage. The latest coverage report shows 1347 lines covered:
https://storage.googleapis.com/oss-fuzz-coverage/meshoptimizer/reports/20260429/linux/src/report.html

Can confirm locally these changes get coverage to 4000+ lines.

[zeux]

I'm open in principle to expanding the fuzzing support here. I'm wondering if it would make sense to consolidate things a little further.

Right now we have codecfuzz, simplifyfuzz & clusterfuzz; this would add two more, but optimizefuzz isn't actually scoped to just the optimization code (it calls generateTangents!). From the report above I assume OSS-Fuzz isn't currently using simplify/cluster fuzzing suites.

I think it would perhaps be cleaner & better if most of these would be merged into a single source, like tools/fuzzer.cpp? This could keep your existing code in this PR, merged into a single file, and also incorporate code from simplify/clusterfuzz? simplifyfuzz & clusterfuzz are currently using rand() to generate vertex data so I'd imagine this would need to use the data provider.

This would then make it easy to extend fuzzing support as new algorithms are added: instead of extra fuzzing suites that partially replicate the data generation, it could just be a matter of adding a few more calls to the "main" fuzzing driver, and OSS-Fuzz would presumably pick the changes up automatically.

I would still keep codecfuzz as the only separate fuzzing suite; so with this proposal we'd have codecfuzz.cpp and fuzzer.cpp. The reason is that the codecs are somewhat fundamentally different in scope: it's the only code that is designed to run on client computers and operate on fundamentally untrusted data. All other algorithms - simplification, cluster generation, and every algorithm added in this PR - should still be crash proof under fuzzing, but they are much more rarely deployed in security-sensitive situations. Because of this running codecfuzz in isolation can provide more focused and comprehensive fuzzing, so it should still be separate.

Open to feedback on the above.