This change syncs the public header include install location with what gets written into pkgconfig file.

To avoid target exe file export JSON functions.

Some users may not want to included it in their build/system. So allow a
cmake symbol to disable it.

A user can do 'cmake -DDISABLE_JSON_POINTER=ON <json_c_root_dir>' and
disable the json_pointer functionality. That saves about 17 KB (on an
x86_64) machine. This may be useful on smaller embedded systems; even
though the saving would be fewer kilobytes.

One thing that also needs to change a bit, is that the 'json.h' be
autogenerated via cmake, in order to conditionally include that
"json_pointer.h" file.

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>

Fixes the following warning:

json_pointer.c:230:7: warning: implicit declaration of function
    'vasprintf' is invalid in C99 [-Wimplicit-function-declaration]
            rc = vasprintf(&path_copy, path_fmt, args);

Lower overhead than opening & reading from /dev/urandom, and works
in chroots and other situtations where /dev/urandom is not available.
Falls back to existing methods when kernel doesn't support the syscall.

Example:
mkdir build && cd build
cmake -DOVERRIDE_GET_RANDOM_SEED='do { extern uint32_t getMsTicks(void); int ms = getMsTicks() * 433494437; return ms; } while(0)' ..

With this version script, newly-linked binaries that depend on the
json-c shared library will refer to its symbols in a versioned form,
preventing their references from being resolved to a symbol of the same
name exported by json-glib or libjansson if those libraries appear in
dependency search order before json-c, which will usually result in
a crash. This is necessary because ELF symbol resolution normally uses
a single flat namespace, not a tree like Windows symbol resolution.
At least one symbol (json_object_iter_next()) is exported by all three
JSON libraries.

Linking with -Bsymbolic is not enough to have this effect in all cases,
because -Bsymbolic only affects symbol lookup within a shared object,
for example when json_object_set_serializer() calls
json_object_set_userdata(). It does not affect calls from external
code into json-c, unless json-c was statically linked into the
external caller.

This change will also not prevent code that depends on json-glib or
libjansson from finding json-c's symbols and crashing; to prevent
that, a corresponding change in json-glib or libjansson would be needed.

Adding a symbol-version is a backwards-compatible change, but once
added, removing or changing the symbol-version on a symbol would be an
incompatible change that requires a SONAME bump.

Resolves: https://github.com/json-c/json-c/issues/621
(when combined with an equivalent change to libjansson).

Signed-off-by: Simon McVittie <smcv@collabora.com>

Json object split

json-c has symbol collisions with other popular C JSON libraries.
To prevent random crashes in downstream applications that may use a
library which depends on json-c, the solution is to statically link
libjson-c.a into those libraries.

`-fPIC`/`-fPIE` is required when building a `.a` so it can be linked
into a `.so`.

The default is now that string data is stored inline at the end of json_object, though to allow for json_object_set_string() to set a _longer_ string, we still need to allow for the possibility of a separate char * pointer.
All json types have been split out now, next step it cleanup.

Using thread-local storage may not be desired in all environments
and/or use-cases, thus there should be an option to disable its use
on purpose.

Fixes #451.

This is intended to provide a way, during development, to test out the memory
and performance impacts of a change.

On Windows, or at least when cross-built with Mingw-w64, build fails
because strict prototype fails on an included file (thus nothing we can
do about in json-c code):

> from /home/jehan/dev/src/json-c/json_util.c:44:
> /home/jehan/.local/share/crossroad/roads/w64/json-c/include/minwindef.h:196:3: error: function declaration isn't a prototype [-Werror=strict-prototypes]
>   196 |   typedef INT_PTR (WINAPI *FARPROC) ();
>       |   ^~~~~~~
> /home/jehan/.local/share/crossroad/roads/w64/json-c/include/minwindef.h:197:3: error: function declaration isn't a prototype [-Werror=strict-prototypes]
>   197 |   typedef INT_PTR (WINAPI *NEARPROC) ();
>       |   ^~~~~~~
> /home/jehan/.local/share/crossroad/roads/w64/json-c/include/minwindef.h:198:3: error: function declaration isn't a prototype [-Werror=strict-prototypes]
>   198 |   typedef INT_PTR (WINAPI *PROC) ();
>       |   ^~~~~~~

Let's just disable the errors for Windows build.

The default location for pkconfig files on most systems is:
  ${CMAKE_INSTALL_LIBDIR}/pkgconfig

Thus the file should get installed in there by default.

Linking with '-Bsymbolic-functions' is supported for ELF-binaries, only.

There was a typo in `CMAKE_SHARED_LINKER_FLAGS`.

Add uninstall target in cmake