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

modify json-c default build type, and fix up the assert() errors in t…

add uint64 data to json-c