lib/external/parson: use G_malloc and G_free internally

[nilason]

Use G_malloc and G_free internally in Parson.

• libgrass_parson library now depends on libgrass_gis
• wrap G_malloc in private function adapting to JSON_Malloc_Function definition
• G_json_value_init_object and G_json_value_init_array always return allocated object
• parson is initialized lazily using C11 atomic operation

[wenzeslaus]

Can you please specify here what is the big picture? Like all library functions result in fatal on non-recoverable errors...

[nilason]

Can you please specify here what is the big picture? Like all library functions result in fatal on non-recoverable errors...

Yes, but not only library, modules as well use G_malloc. Current G_malloc's most advantageous feature is that it calls G_fatal_error on failure to malloc (with informative error message) and in the extension the caller of G_malloc is guaranteed to receive a non-null object, rendering return value checking superfluous (with help of __attribute__((returns_nonnull))).

It occurred to me now that stdatomic.h is only optional part of C11, although nowadays current compilers generally support it (including Visual Studio 2022). The question is whether I should guard its use, or let us see if this leads to problems "in the wild" and act accordingly at that time.

[nilason]

I added a simple fallback for C11 compiler without support for atomic operations, this adds a small risk of undefined behaviour (in case of data race). While Parson library is not thread safe in itself, the lazy initialisation adds a potential, however minuscule, risk.