Although it is currently working, it's worth to stick with the stdlib definition to avoid further problems

This is a recent regression since commit
6359b79847 which added various assert(0)
calls (often replacing return-s).
With Ming-W64 compiler, json-c build was failing with various errors of
the sort:

> /home/jehan/dev/src/json-c/json_object.c: In function 'json_object_int_inc':
> /home/jehan/dev/src/json-c/json_object.c:841:1: error: control reaches end of non-void function [-Werror=return-type]
>   841 | }
>       | ^
> In file included from /home/jehan/dev/src/json-c/json_object.c:17:
> /home/jehan/dev/src/json-c/json_object.c: In function 'json_object_get_double':
> /home/jehan/.local/share/crossroad/roads/w64/json-c/include/assert.h:76:4: error: this statement may fall through [-Werror=implicit-fallthrough=]
>    76 |   (_assert(#_Expression,__FILE__,__LINE__),0))
>       |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /home/jehan/dev/src/json-c/json_object.c:1070:7: note: in expansion of macro 'assert'
>  1070 |       assert(0);
>       |       ^~~~~~
> /home/jehan/dev/src/json-c/json_object.c:1072:3: note: here
>  1072 |   case json_type_boolean:
>       |   ^~~~

The problem is that Mingw-w64 does not consider assert() as a noreturn
(even assert(0)), because it has to be compatible by Microsoft
libraries. See the discussion here:
https://sourceforge.net/p/mingw-w64/bugs/306/

Instead let's create a new json_abort() function which is basically just
an abort() function with an optional message, for such cases where
abortion was non-conditional (using assert() and using the assertion
condition as a message here was clearly a misuse of the function). And
mark json_abort() as 'noreturn', as well as 'cold' for optimization
purpose (this is code we expect to never run, unless there is a bug,
that is).

Finally let's use this json_abort() instead of previous misused assert()
calls.

Though we will no longer be comparing exactly against INT64_MAX, this is ok
because any value of that magnitude stored in a double will *also* have been
rounded up, so the comparison will work appropriately.

Fixed misalignment in JSON string due to space after \n being printed...

json_object_private: save 8 bytes in struct json_object in 64-bit arc…

json_object.c:set errno in json_object_get_double()

I also added a couple trivial, but related, suggestions.

closes #460

closes #422

- there is no need for _ref_count to be uint_fast32_t (the compiler
  might decide to use a 64-bit int). make it uint32_t instead.
- reorder the 32-bit integer fields (o_type and _ref_count) so that
  there is no wasted 4-byte gap after each of them.

Also try to accomodate formats to explicitly exclude the decimal (e.g. %.0f).

Because doing `json_tokener_parse(json_object_get_string(src))`
feels sloppy, dirty, and makes me want to cry at night
sometimes.

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

Found with autofuzz in GDAL

merge upstream

Add a comment mentioning the limitation even though the _ref_count value is hanled atomically.

This is EmielBruijntes' "Atomic updates for the refcount"

want to merge the original repository

2.replace json_object_get/put API with json_object_retain/release, as they operate the reference counter, and confused with array_list_get/put_idx.
3.replace array_list_get/put_idx API with array_list_get/insert to make them more clear to use.