Move bundling of JSON-C to CMake.

[Ferroin]

Summary

Similar rationale to #17190, our handling of JSON-C suffers from the same potential discrepancy between how our installer code sees the build environment and how CMake sees it. Shifting JSON-C vendoring into CMake eliminates that issue, and also allows for slightly better parallelization of the build/install process.

Test Plan

We actually validate vendoring of JSON-C in CI, so testing should not require anything other than confirming CI passes on this PR.

[Ferroin]

Rebased to resolve merge conflicts and pick up latest changes.

[Ferroin]

Rebased again to pick up latest changes in master.

[vkalintiris]

If you address my comment (or disagree with it) feel free to red button this.

[vkalintiris]

Please, don't do this. Over time it will become difficult to figure out easily the dependency DAG of targets.

[Ferroin]

I’m not sure how this significantly complicates things, unless you’re using some external script to parse the CMakeLists file and try to figure out the dependency graph from that.

This function being called on a target says quite clearly that that target depends on JSON-C. And because of how CMake handles adding dependencies, you need to be searching the whole file for the target name anyway instead of just blindly looking for target_* calls on the target. I’m also trying to follow a netdata_add_*_to_target pattern for functions like this so that they are easy to find and properly descriptive.

To clarify, my intent here is to keep all the arcana involved in getting this to actually work properly encapsulated. By handling it like this, anybody working on the build system won’t need to remember the names of the variables used to add JSON-C to a target, or where they are set, or whether the include directories need to be appended or prepended to the search list, or the fact that you need to add a supplementary dependency to the target to ensure that headers can be found correctly when using a vendored copy of JSON-C.