OSS-Fuzz: Move fuzzers upstream and add a new fuzzer targets json processing

[arthurscchan]

At present, all OSS-Fuzz fuzzing for GEOS lives solely in the OSS-Fuzz repository (https://github.com/google/oss-fuzz/tree/master/projects/geos), where the harnesses, their CMake glue, and the seed corpora are carried as a patch.diff applied on top of a pristine GEOS checkout at build time. As a result, fuzzer development happens entirely outside this project, with no straightforward way for the maintainers to review or monitor it. This PR proposes moving the fuzzers, their build configuration, and their corpora into a dedicated directory in this repository (for example tests/fuzz/), wired into CMake behind an opt-in target so they are never built in a normal build. This keeps the harnesses in step with the library and needs no further OSS-Fuzz-side changes when fuzzers are added or modified, since OSS-Fuzz would simply build whatever is present in the upstream fuzzing directory.

Alongside this, this PR also adds a new fuzzer that targets the GeoJSON processing in GEOS, together with the seed corpus and dictionary for the new fuzzer.

The OSS-Fuzz side changes can be found in google/oss-fuzz#15757 and will only be merged after this one is accepted.

Of course, this is only a suggestion. If the maintainers would prefer the fuzzers to remain in OSS-Fuzz, I am happy to keep the current setup and to ping the relevant maintainers for review whenever I add new fuzzers later in the process.

Thank you for considering this, and I would welcome any feedback on the preferred approach.

[gdt]

Are there licensing implications? Is the upstream repo and all tools one needs to run the tests Free Software? Are they packaged e.g. for Debian (and packagable for others), so ti's reasonable for anyone to just check out geos, install some extra deps, give some cmake arg, and run them? (I would hope so, but Coverity.) If that's all ok, this seems like a good idea. If it's not, then it seems problematic to me.

[pramsey]

Rebase to pick up the fix to the windows CI.

[arthurscchan]

Hi, sorry for the late reply.

To clarify what this PR does: it moves the fuzzers from OSS-Fuzz into the geos repository itself and integrates them into the CMake build system.

A bit of background. The fuzzers themselves have no licensing requirements when it is moving out of the OSS-Fuzz. Until now, they lived entirely in OSS-Fuzz, which runs daily on Google Cloud. It clones geos, builds the fuzzers and fuzzes them each day. With this PR, the fuzzers become part of the geos repository and its CMake build, so anyone can simply clone geos and build them as normal. OSS-Fuzz will continue to build and fuzz them too, now using this integrated CMake build rather than its own separate setup.

I think this benefits geos users directly, as they can build and run the fuzzers themselves without depending on OSS-Fuzz. It should also make it much easier to add further fuzzers to geos in future.