Find nlohmann_json dependency in cmake config file when proj is confi…

[dirkvdb]

Possible fix for issue #2762

• Closes CMake targets broken in 8.1.0 when using external nlohmann_json #2762

[rouault]

It doesn't feel right to have nlohmann/json requirement exposed to external users of PROJ, as it is purely an internal implementation detail

[hobu]

I concur with @rouault.

I guess I haven't been tracking so closely, but did we ever advertise that we would work with an external nlohmann? The established pattern is for projects that use it to vendor it, namespace it, and then not leak it into their external APIs. This is because many other libraries, PDAL in my case, are also using nlohmann, and the opportunity for misery increases substantially if libraries it is using start doing putting their own vendored copies in their public APIs.

[rouault]

I guess I haven't been tracking so closely, but did we ever advertise that we would work with an external nlohmann?

I'm culprit for that. This has been added in 8.1 as an option. If using external nlohmann, then the official namespace is used (and that way folks combining different libraries that use it can save some binary space, and this is more friendly of distributions w.r.t security issues). If using internal nlohmann, then the proj_nlohmann namespace is used to avoid potential version clash.
I'm not sure why cmake insists about having to require nlohmann when using the library. It probably lacks hints that this is a header only dependency and that the nlohmann headers aren't exposed in our own headers

[rouault]

Superseded per #2780