Fixes https://github.com/json-c/json-c/issues/647

In practice, the sizes of the signed and unsigned integer types will
almost cetainly be the same, but this is more correct.
Pointed out in issue #638.

This causes previously failing strings like "123-456" to return a valid json_object with the appropriate value.  If you care about the trailing content, call json_tokener_parse_ex() and check the parse end point with json_tokener_get_parse_end().

Also add the json_object_new_array_ext, array_list_new2, and array_list_shrink functions.

Remove all of the temporary defines, structures, old compat fuctions, extra fields, etc... that were needed during the conversion to a split set of json_object_* structures.

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.

Clean up the code in json_object_new_* a bit by dropping unnecesary json_object_base variables.

The current changes split out _only_ json_type_object, and thus have a number of hacks
 to allow the code to continue to build and work.

Originally  mentioned in issue #535.
When complete, this will probably invalidate #552.
This is likely to cause notable conflicts in any other significant un-merged
changes, such as PR#620.

A custom double formatter can lead to truncation of the rest of the
JSON document.

If a custom formatter completely fills the buffer used by snprintf
with a trailing dot or comma and the formatting option
JSON_C_TO_STRING_NOZERO has been specified, then an iterator moves
past the ending '\0' (off-by-one buffer overflow) to set an
additional '\0' and adds the first '\0' into the printbuf.

Since '\0' will eventually be considered the terminating character
of the complete printbuf result, all trailing characters are lost.

This leads to an incomplete JSON string as can be seen with the
test case.

The off-by-one can be noticed if compiled with address sanitizer.

Since this is a very special case and a malformed formatter could
do way more harm and is the responsibility of the user of this
library, this is just a protective measure to keep json-c code as
robust as possible.

Fix compiler errors and warnings when building on IBM operating systems such as AIX and IBM i.

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.